Spent a couple of days this week chasing down a crash on a pre-release BREW 3.1.5 handset.

The handset rebooted when I exited my application, which was, err, not ideal. It turned out that the crash was caused by releasing (and thereby destroying) an IROOTFORM while handling EVT_APP_EXIT. Remove that line (and leak the object) and the crash went away. Clean up a whole bunch of other objects? Still no crash.

This was starting to look seriously like some weird bug in my code - I mean how can releasing an IROOTFORM (but not, say, an IFORM) cause a crash?? So I wrote a 20 line application that replicated the bug and reliably crashed the handset. OK, now it was starting to look like the handset was at fault. I got someone to review my code, tested it on some other handsets, scratched my head, and decided that the OEM must have messed something up.

One of the problems with working on mobile phone platforms (especially pre-release, though unfortunately well-sold commercial handsets are not immune) is that the OEM is working to a tight timescale, and when it comes to the crunch, QA on the Java Engine/BREW implementation is one of the first things to go. Of course, by and large problems aren't the OEM's fault, and when chasing bugs it's important to remember this; many times we've been sitting at our desks swearing at the OEM (or even QUALCOMM) only to discover that the bug is staring us in the face in CodeWeWroteLateLastNight.c.

My test app is now with QUALCOMM who will pass it onto the OEM. I can only hope that my days of heartache will result in a fix ;-)