07-14-2009 03:45 PM
We are seeing a problem on our application where the phone reboots, apparently randomly. We have done a lot of testing on both the 8320 and the 9000, and we only see it on the 9000 (multiple handsets). It happens rarely (and seemingly never when I'm trying to get it to happen), but enough that it's a serious problem. Most of the instances have been reported by other users, but I have personally seen a crash myself upon clicking 'OK' on the 'No message services configured. You will only be be able to Save Draft' popup when launching the email application from our application via invokeApplication().
We have been looking at the system logs of phones after this happens. There is nothing overtly suspicious in the logs. Our application is always running even when in the background, but the crashes seem to happen around when the application is 'active', i.e. it is in the foreground, and/or using the network.
We have also seen errors with the application event queue overflowing, so we're wondering if this could be related to the crash. One thing we are looking at is our use of modal screens, typically displayed using pushGlobalScreen(), since this is possibly the only time we block the event thread. For example, when our application is not visible, we capture a keyDown() (since the app is always running in the background), from which we push a modal screen--effectively blocking in keyDown() until the modal screen is dismissed. The modal screen is dismissed on keyUp(), after which keyDown() will finally return. As I understand it, while pushGlobalScreen() will block, a new thread takes over the event processing while the modal screen is up, until the screen is dismissed, when the original thread takes over again--could something be going wrong here causing the event queue to overflow?
So really we have two problems which may be related--the event queue overflowing, and the phone completely crashing. Any ideas on what could be causing one or both of these issues?
09-16-2009 11:07 AM
We seem to have improved things, although I'm pretty sure it's still lurking and happens occasionally. And it's hard to nail down exactly what we've done that helped, because the issue is difficult to reproduce (until you're not trying to reproduce it, of course). But here are some things we've done:
We're overly careful not to fill up the application event queue. As in, we've created our own queue that we use instead of invokeLater() in most cases, which doesn't even stick events in the app event queue until the previous event has finished. Slow, but fine for our application. I don't think this has helped the reboot, but I suppose it has helped with the event queue overflow since we don't see it anymore.
We now do all our network calls on the same thread. We found that on the Storm we could get the phone to reboot consistently, and the source of the problem was the non thread safety of the network stuff.
We are better about how we use modal screens. Displaying a modal screen actually causes your application UI thread to cease, and a new thread belonging to that modal screen takes over until the modal screen is dismissed. This can have some unexpected (to me anyway) side-effects if you're not careful.
And we've cleaned things up in general.
09-16-2009 03:03 PM
Thanks for posting your findings, I too am having a reboot issue..
Managing all network activity through a single thread is less than ideal for a highly interactive network application.
Has it been documented that the RIM network stack is not thread safe? That would seem to be a very significant limitation. This would significantly impact the user experience in our application if we have to communicate with only a single thread
We too see the issue happen most frequently on the Storm. Do you have any insight into how you narrowed down the issue to the network activity? I would like to confirm this to be the case before I go ahead and rework all of the network code we have in place to run all communications in a single thread.
Thanks for your help.
08-17-2010 12:24 PM
I'm seeing a similar problem where the Storm reboot seems to have some connection to the networking interface. We are willing to pay for help with this problem.
09-10-2010 09:54 AM
We've seen our share of phone reboots linked mostly to Wi-Fi activity, usually when closing and then opening a socket. It seems a kind of regression in BlackBerry OS 5.0, because it would happen only there, the same application working just fine on both earlier and later versions of OS. Bold 9000/9700 are less likely to crash like that, but both Storm and Storm 2 reboot with frightening regularity.
12-21-2010 02:13 AM
I had the same problem (on Curve devices OS 5.0) and almost same scenario (8-10 threads for downloading image) and got a work around. What I did:
1. Create a request queue for all image downloads.
2. Add to queue an image download request when needed.
3. Create a thread (only one thread it is important) which is listening for this queue.
4. If there is no request in queue do nothing wait.
5. If there are one or more request in queue (waiting to be download), Take one request from queue and download that image (you can use an while loop for this purpose).
6. When an image completes its downloading update UI Field which corresponds to this image. You can create an interface for this purpose or anything else which fulfills your requirement.
7. Remove this request from queue.
8. Sleep for 500 millisecs.
9. Repeat Steps 5-9 until all request are done.
@knight9, I think we should have only one or two threads for raw data download (I do not know it's a blackberry limitation or something else) and for other simple http requests which do not have to deal with large amount of data (plain text data), you can create threads on demand (Right now I am doing this and My App is fine with that).
Hope this will help you.