Comment 5 for bug 691378

I still don't have a perfect stacktrace, but for the past week I've run audacious exclusively in gdb, and I now have a gdb session transcript for a session where the bug occurred. It shows some information about the I/O errors that occurred immediately prior to the crash, and gdb was able to generate this stack trace (excerpted from the complete transcript, which is attached):

#0 0x00007ffff544c6b6 in __lll_lock_wait () from /lib/libpthread.so.0
#1 0x00007ffff5447849 in _L_lock_953 () from /lib/libpthread.so.0
#2 0x00007ffff544766b in pthread_mutex_lock () from /lib/libpthread.so.0
#3 0x00007fffe895e5b5 in ?? ()
#4 0x00007fffd4001bf0 in ?? ()
#5 0x00007ffff5448c70 in ?? () from /lib/libpthread.so.0
#6 0x0000000000000001 in ?? ()
#7 0x00007ffff6c677e4 in g_thread_create_proxy (data=0x63fee0)
    at /build/buildd/glib2.0-2.26.1/glib/gthread.c:1897
#8 0x00007ffff5445971 in start_thread () from /lib/libpthread.so.0
#9 0x00007ffff4d8d92d in clone () from /lib/libc.so.6
#10 0x0000000000000000 in ?? ()

Since the package libc6 provides both /lib/libpthread.so.0 and /lib/libc.so.6, I've installed libc6-dbg. I will continue to run audacious in gdb with the hope of generating a better stack trace. But since weeks sometimes pass between occurrences of this crash, I'm posting what I have, in case it's useful.

One clarifying note: the binary /usr/bin/audacious is a symlink to /usr/bin/audacious2.