08-22-2008 10:19 AM - edited 08-22-2008 12:15 PM
I'm using OS version 18.104.22.168 on an 8800 as released by Vodafone Germany. I'm forced to use a relatively up to date OS as I need features added in 4.3 for the rest of my app. I can't confirm whether or not the issue happens on any other OS versions at the moment, I should have access to an 8120 next week which has whatever version of 4.3 on it that O2 UK are currently shipping. Until then though..
Essentially I can make the device reboot without warning, and the only difference between a version of the program where this happens and one where it doesn't appears to be use of the class ZLibOutputStream. With Zlib I can open up client server connections (the Blackberry is the server, for what it's worth) which stay open for as long as I like (at least half an hour I've specifically timed but I have no reason to believe they won't stay up as long as the over-the-air TCP connection holds). I made a modification to pipe some of the data I'm sending through ZLib just to ease the overall amount of data that needs to be send. In the simulator this works well and provides something of a speed increase. However on the device connections last some variable (but always short) amount of time before I get a reboot - screen goes black, red LED lights up, then after a few seconds I get the sand timer and booting begins.
I've repeated this countless times, and if I configure the program to only allow connections without ZLib then everything goes back to being very stable. The output shown in the JDE debugger, if I attach to the device and then cause it to crash, shows nothing out of the ordinary. The event log from a typical crash yields nothing:
guid:0x97C9F5F641D25E5F time: Fri Aug 22 14:45:13 2008 severity:0 type:2 app:System data:CMM: bbserverapp(6557) no sig from 0x33
guid:0xC1A90F9B4F904C57 time: Fri Aug 22 14:45:13 2008 severity:5 type:2 app:App Perms data:d bbserverapp:29
guid:0x97C9F5F641D25E5F time: Fri Aug 22 14:45:33 2008 severity:0 type:2 app:System data:VM: 600001 gc=0 idle=0 native=net.rim.device.internal.io.socket.NativeSoc
guid:0x97C9F5F641D25E5F time: Fri Aug 22 14:45:33 2008 severity:0 type:2 app:System data:System Startup
guid:0x97C9F5F641D25E5F time: Fri Aug 22 14:45:33 2008 severity:0 type:2 app:System data:VM:FSNHv=
I've added a blank line where the crash is.. the two lines before the crash are the end of a run of many of them, even though one of them is severity 5 I don't see that as a direct cause because I've got any number of them in the log. The "permissions" part most likely refers to the screenshot taking part, for what it's worth. Permissions are definitely configured correctly because the app performs correctly (takes screenshots and sends that data across the network). ZLib seems to be the cause of the problem, but it's not as simple as instantiating or using the class causes the reboot - sometimes I've had the connection work for 10 or so seconds - data is definitely being compressed correctly as it appears fine on the other end.
I'm leaning towards this being some problem with memory filling up (compression can eat up quite a large proportion of a handheld's memory I imagine) or bug in the JVM, but it's hard to reproduce it in a precise enough way to be positive, all I am definite about is that ZLibOutputStream is involved. I can definitely just switch off the feature, but the decrease in data that must be sent is invaluable, and I would really like to use the RIM native ZLib for speed rather than find some third party version.
Thanks for reading this far if you have, bit of an epic I know but I didn't want to leave out anything.. Any help or advice anyone has would be much appreciated.
Edit: I've been running further tests.. the reboots still happen even with the ZLib window size set to 8 (the minimum) and the compression level set to zero (intuitively this should use the least memory possible, as there is no compression so all the ZlibOutputStream has to do is prepend / append the header / footer data). I think something must be seriously broken in this class.. I'm going to try a full device wipe / OS reinstall just in case something got corrupted at some point.
08-25-2008 09:32 AM
08-27-2008 09:20 AM
I've now confirmed that this is not an issue on a Pearl running some flavour of 4.3 so I'm happy my code is fine. I'll be sending in as much detail as I can to that email address so hopefully a fix can be developed for 4.5.
Thanks for your help.