rtitmuss Wrote: > > It would be really useful to know which thread is spinning > and the stack trace of the thread (running Softsqueeze from the command > > prompt press Ctrl-Break to get a thread dump), and bonus points for > spotting why :). > > Richard
as requested, thread dump is attached. It takes a while to get into this state. At least 30 min (~6 tracks), exact time, I don't know, as I went to a meeting. The memory wasn't so bad this time, but CPU usage did spin up to whatever was allowed. Pausing the player did pause the output, but had no impact on CPU utilization (which should indicate there's an unused thread spinning). >From the dump, it looks like only "SlimTCP-2" prio=7 tid=0x072cdb10 nid=0x1204 runnable [797f000..797fd8c] "SlimUDP-0" prio=5 tid=0x072c3470 nid=0xd80 runnable [773f000..773fd8c] "AWT-Windows" daemon prio=7 tid=0x02e56850 nid=0x1354 runnable [71af000..71afd8c] aren't waiting on an Object lock or condition. "AudioDecoder-16" daemon prio=7 tid=0x02cb3948 nid=0x12b0 waiting on condition [7abf000..7abfd8c] is suspicious because "AudioDecoder-18" daemon prio=7 tid=0x02d4c0d8 nid=0x70c in Object.wait() [7aff000..7affd8c] exists. What happened to 17? Why is 16 waiting on a StringBuffer.toString() call? This seems like odd behavior for an AudioDecoder to be locked on. This is a daemon thread, which seems strange as well. Perhaps not cleaned up appropriately. Might be worth the time to stick a logging finalize() in this class to see when they're getting cleaned up... FWIW, -bill +-------------------------------------------------------------------+ |Filename: ss.txt | |Download: http://forums.slimdevices.com/vb/attachment.php?attachmentid=85| +-------------------------------------------------------------------+ -- wyldbill _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
