09-10-2009 05:07 PM
I have a multi-threaded application I am running on a BlackBerry 9000. I suspect there are deadlock issues.
i figured out how to trigger the stack trace using javaloader -usb logstacktraces (rather than wait for the "not responding" error alert), and can fetch them using javaloader -usb eventlog , but I am having trouble interpreting them.
When I develop normal java applications I can use ^\ to get a thread dump that includes source files, line numbers, and (most importantly) a list of locks and blocks, telling me who has a lock on an object, and who is blocked waiting for a lock to be released (either via method exit or wait() call).
I do not know where that information is within the Blackberry stack traces.
guid:0x9C3CD62E3320B498 time: Thu Sep 10 15:51:37 2009 severity:0 type:3 app:Java Exception data: ForcedStackTraceException baconology(160) 33 2 0x482E4000 baconology(4AA957F5) BlockRun nap 0x3EF baconology(4AA957F5) BlockRun waitForBuffer 0x4BF baconology(4AA957F5) PiecewiseSourceStream read_ 0x14D7 baconology(4AA957F5) PiecewiseSourceStream read 0x1570 net_rim_cldc-16(4A739706) DataSourceInputStream read 0x25AF net_rim_media(4A739765) MP4Info <private> 0x34E1 net_rim_media(4A739765) MP4Info <private> 0x2DA7 net_rim_media(4A739765) MP4Info <private> 0x2D63 net_rim_media(4A739765) MP4Info <init> 0x33A8 net_rim_media(4A739765) StreamingMediaPlayer doRealize 0x9224 net_rim_cldc-16(4A739706) BasicPlayerImpl realize 0xF80 baconology(4AA957F5) JMFToy fabricateAndRealizePlayer 0x9F5 baconology(4AA957F5) JMFToy$3 run 0xD94 net_rim_cldc-1(4A739706) Thread run
Since that thread is stuck waiting to enter the BlockRun.nap() call, I can assume it's blocked, waiting for a lock on *this*, because otherwise it would be inside the Object.wait() function, waiting for another thread to issue a notifyAll().
What I need to know is which thread has the lock, so I can arrange for it to be released, or not acquired at all.
Solved! Go to Solution.
09-10-2009 05:26 PM
Sorry, I can't help with your traces.
I am hoping that you are developnig using the JDE and can test this in that environment, in which case the following KB article may be of some assistance:
How to - Detect a deadlock using the JDE
Article Number: DB-00572
09-10-2009 05:37 PM - edited 09-11-2009 05:46 AM
Each stack trace (one thread) starts with the name of the process that owns the thread, followed by the process ID in parentheses, then by thread ID, then the thread state (1 = RUNNABLE, 2 = WAITING, 3 = TIMED WAITING, 4 = BLOCKED), then the ID of the lock on which the thread is performing a wait() or the ID of the lock the thread is blocked on (waiting to acquire).
After the stack traces there's a list of locks. The list tells which threads own which locks and the Java class names of the locks.
The information in stack traces and the list of locks is sufficient for an automated tool to analyze the dependencies between threads and to also find dead-locks (if any). I have depeloped such a tool (so, it's possible, and it's not hard to do), but I'm not at liberty to release it.