frustration ;-(

Things have been going swimmingly up to this point. Last night I got touch events going into the app. Again just capturing the java touch events in my view and then calling their native counter parts in my game. So the game loop actually started... and then crashed about 3 seconds later.

Ok, now for debugging my c library linked into my java app. I knew I needed to set things up sooner or later. A few google queries later I find how to debug with ndk and I'm convinced I need to upgrade my eclipse from 3.5 to 3.6. I find 3.6.1 and decide to go with the latest. I try downloading the eclipse plugin from Sequoyah Project, but it says there's no files available. Hmm, perhaps I have too new a version of eclipse? I download the older 3.6. Again the install from within eclipse can not find any files to install from their site. So I download the zip file of the plugin and then try to install from zip archive in eclipse. Still it says there's no files to install. I try setting up the debug settings in the original post. I repeat my steps about 3 times and give up.

I decide to try the debug setup without the Sequoyah plugin. Now the problem is that it says my project is not a c project and can't do a c debug session. So I create a c project to build my jni source. Then I launch my java project, load the c library and break. I try to but it won't let me launch the c build because it says there's no target. I notice that the debug project specifies to use the armprocess file in the obj dir when debugging. That doesn't work.

I find a bunch more posts from people that have just given up on eclipse debugging, and I can understand why. I decide to try command line debugging. There's a debug script that's in the lib folder. I launch my java app, step past the loading of my c libary and break the java app. I'm able to connect to the running process through ndk-gdb script. Cool! I set a breakpoint on my load function - b LoadFile. Then I type continue. The app runs past my breakpoint and crashes. I try again, set my break and then continue the java app running. It ignores my breakpoint and crashes. I try 4 or 5 variations I can think of. Repeat a few that I'm sure should have worked. I restrain my urge to punch in my monitor. I don't need to buy a new one, and I'd probably just injure my hand.

Ok. Not working. At least I'm getting a stack trace from logcat. I add some commands to generate a map file and then look up the stack addresses. It appears that the path generation is crashing. By now I feel like I wasted hours and no further on what might be a simple fix. I decide to start the tried and true - printf debugging. Luckily there's a handy function I can call from c to send text to logcat.

Now at least I'm making slow but forward process towards finding the real problem. An hour of binary search leads me to suspect on of the routines in my hand rolled vector routine. I realize my error and make the small fix. Finally.

I may revisit my steps more slowly. Perhaps I was too impatient. I feel I'm usually one that figures things out fairly quickly. After 3 or 4 hours of failure I start blaming the process. Perhaps that's my problem. I have too much pride and start blaming the tool chain instead of patiently retracing my steps. I resolved to find some more authoritative docs and give them a thorough read when I'm more rested.

I left out the part where I tried to install STLPort and failed to find sufficient indication of how to build it under the andoid ndk. I think that's my best bet long term.