I've experienced frequent hangs (symptom: the song already playing is played until it ends, while the ui is already frozen) since a while and investigated a bit. For once there've been a few race issues fixed in branch in between (patch follows), but these fixes unfortunately didn't cut it, so I started gdb (gdb) bt #0 0xb6e95b2e in malloc_consolidate () from /lib/libc.so.6 #1 0xb6e97cf1 in _int_malloc () from /lib/libc.so.6 #2 0xb6e9930e in malloc () from /lib/libc.so.6 #3 0xb3922216 in scope_port_put_buffer (port_gen=0x8d31490, buf=0x8b53768, stream=0x8a1cb78) at xine-scope.c:81 #4 0xb0bb30d4 in mad_decode_data () from /usr/lib/xine/plugins/1.1.8/xineplug_decode_mad.so #5 0xb38ddc42 in audio_decoder_loop () from /usr/lib/libxine.so.1 #6 0xb704818b in start_thread () from /lib/libpthread.so.0 #7 0xb6ef104e in clone () from /lib/libc.so.6 Searching a bit I stumbled about https://bugzilla.redhat.com/show_bug.cgi?id=284171 which is fixed in glibc 2.7, but not 2.6. I'd prefer to stay with stable glibc, but well... Care to backport or do you prefer to push me towards 2.7, Mike?
Created attachment 137749 [details, diff] amarok-1.4.7_post20071120.diff
The patch is pointless, I do follow Amarok's SVN and I'm good enough to actually use svn diff to get it myself if I need it. The backtrace is useless, you should have at least used thread apply all bt, but that's not the problem either, as it would probably just point me at one of the many deadlocks in xine's code. You also don't seem to provide useful information like the engine used in Amarok (although this can be deducted by the backtrace, it's xine), the type of file playing (just MP3s or also other filetypes?), or the output plugin used. If you think the problem is fixed in SVN, please at least *test* it through amarok-1.4.9999, if it works fine there I'll push for a new amarok release or prepare a snapshot tarball - no I'm not going to apply the patch to update from 1.4.7 to 1.4.8.
