Thank you for visiting the BlackBerry Support Community Forums.
BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)
BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.
"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."
- Kevin Michaluk, Founder, CrackBerry.com
Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.
09-26-2008 12:36 PM
Hi, finally I fix my bug, after spending some time debuging the application, I found the zomby Thread, it just didn´t stop because a varible wasn´t updated, so it keeps living in an infinity loop, thanks to everyone your suggestions to where very helpful to track the problem.
09-26-2008 12:38 PM - edited 09-26-2008 12:39 PM
There are several related issues.
First, OP was concerned GC didn't cull his strong reference.
Second, and I can't find a good reference, there are issues with run() exiting but a thread failing
to terminate due to things like open connections or dumb resource issues. Probably
isalive checks for return from run() but not exit of any native thread or resource
( again IIRC, still searching). This is why I was curious about the cause. If the "real" thread
is still consuming system resources, the next OS call will fail to get more of them.
I think I ran into this in the past but again don't remember specifics and certainly not CLDC JVM stuff.
I'd check for any "irrelevant" references or open resources- IO connections, special hardware like
graphics resources, etc.
I'll post some links if I can find them- I just saw one at blackberry.com that mentioned thread count
as a reason to close stuff but I can't find the link.
[ eh, or , em , you could have an infinite loop somewhere. LOL ]
09-26-2008 03:07 PM
One thing you may want to try, as a test, is to launch a child thread from your run() method and then return.
See how many times you can do this and see what the various counts are. I think that isalive() returns
false once run() returns but the system resources ( effective thread count) may not decrease until things
like children threads die. So, you may only be able to do this MAX_THREAD/2 times as the orphan thread
prevents the system from recording the parent as dead.
I'm trying to refresh my memory and the sun archives are a bit confusing.
Just something to consider if the obvious solutions don't fix things.
09-26-2008 07:55 PM
"One thing you may want to try, as a test, is to launch a child thread from your run() method and then return"
Just done that. The parent Threads terminate, their isAlive gets set false, the ActiveCount reflects the child Threads only, and the processing bombs out as expected after starting 14 parent/child, of which 14 child Threads are still running.
Looks like Rim Thread processing is quite robust!
09-27-2008 09:38 AM
Ok. I can't remember and as I'm sure you know legends get created from simple code bug, LOL.
Anyway, at least earlier IIRC there were conditions in some JVM's where returning from run() didn't mean
everything got released. If you open unique stuff from some thread and it later refuses to die,
it may be something to consider.
Thanks but I would like to find an affirmative case where this happens