JVM Error 523 and Over The Air deployment

[cls]

Hi,

I'm a newbie to java development on the blackberry, so I apologize if this is something obvious. I'm currently writing my first java app for my company, and it is working beautifully in the simulator. However, sometimes when I push it to the device through the BES, it forces the device to restart and I end up with JVM Error 523 (System process died). At this point, the device isn't even usable as a phone and (as far as I can tell) must be plugged into a PC and completely reloaded (javaloader -usb wipe).

I'm trying really hard to understand why this is happening. My app doesn't load on device startup, so to my understanding it couldn't be anything in the code that is causing this (though I have gone back through the code multiple times making sure all exception paths are caught and handled gracefully). I've searched for weeks online to try to find an answer to this but am finding nothing useful. I can't deploy an app to a customer that might render his device inoperable.

I'm hoping I'm missing something obvious here...can anyone shed some light on what can cause this kind of error?

Any help would be very much appreciated!
Chad

[richever]

I'm sorry to hear you're running into such a problem, but I don't have an immediate solution. I was thinking though: have you tried this out on more than one BlackBerry? The device you're using could be faulty in some way. Could there be compatibility issues with the device you're testing on and the code you've written? Sorry I can't be of more help.


Rich

[cls]

I'm not aware of any compatibility issues (not to say there aren't any, but I'm new to this and haven't found any yet). I'm now in the process of recruiting other people to test with me so I can see if it's a bad device or not.

Thanks for the help!
Chad

[cls]

Here's a thought/question...if I close the application, and an update arrives...it shouldn't require me to reset the device, right? If it requires a device reset, does that mean something is left open that shouldn't be? (memory leak? i'm brainstorming here...)

Thanks
Chad

[bglodde]

In my recent past, a very difficult to diagnose JVM 523 was caused by a module that is referenced by an .alx file in the device, but the module no longer existed. Assure your .alx is not referencing a module that is not on the device.

[cls]

Thanks for the idea. I checked the alx file and there is only one .cod file in the fileset. Does it matter in any way that i'm regenerating the alx file every time i deploy? or should I just manually tweak the version number, copy the .cod file, then loader /reindex ?

<fileset Java="1.24">
<directory >
</directory>
<files >
mymodule.cod
</files>
</fileset>


Thanks
Chad

[cls]

New information. I now have 2 devices receiving updated versions of the java app. Sometimes it crashes my device, sometimes it crashes his. It only seems to have this problem if the application has been opened (so if it's never loaded, it never seems to have this problem). I have 2 questions:

1) what can be done to debug this? Is there any way to figure out if some process is left hanging? I'm not sure where to even begin.

2) What's the normal process for sending updates to an app through a BES. Currently I change the version number, recompile, regenerate the alx, sign the cod file through the ide, copy them over the existing versions on the server, then loader /reindex on the server. Is there a better way?

Thanks again!
Chad

[cls]

Just incase anyone was following this...it seems (at least so far) that the BES was somehow corrupting the files when deploying them. They upgraded my BES (to whatever the latest patch level is) and I haven't had a 523 since.

Thanks to those who helped with this
Chad

[cls]

Just incase anyone else had this problem...after a week with RIM support, it was determined that a bug in the handheld 4.0.x software caused multiple copies of the .cod file to be transferred to the device. Upgrading the handheld to 4.1.x fixed it.