which -dbg to install

[Arno Schuring <aelschuring@hotmail.com>]

Hello list,

since updating both gstreamer and alsa this afternoon, I'm having
regular segfaults in quodlibet. However, since ql has not been updated I
have no idea against which package I should file a bug.

So, I set out to catch a core dump, and I'm trying to make sense of the
backtrace but apparently I'm still missing some -dbg files. Here is
what I have so far:

aschuring@neminis:~$ gdb `which python` core
[..]
[New Thread 3134]
[New Thread 3135]
[New Thread 3143]
[New Thread 3144]
[New Thread 3147]
[New Thread 3113]
[New Thread 3114]
[New Thread 3119]
[New Thread 3133]
warning: Can't read pathname for load map: Input/output error.
[Reading symbols..]
Core was generated by `python /usr/bin/quodlibet --start-playing'.
Program terminated with signal 11, Segmentation fault.
#0  0xb0158b4a in ?? ()
(gdb) thread 1
[Switching to thread 1 (Thread 3134)]#0  0xb0158b4a in ?? ()
(gdb) bt
#0  0xb0158b4a in ?? ()
#1  0x00000900 in ?? ()
#2  0x00000000 in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 3135)]#0  0xb7828424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7828424 in __kernel_vsyscall ()
#1  0xb758a696 in __poll (fds=0xb760dff4, nfds=1, timeout=40)
at ../sysdeps/unix/sysv/linux/poll.c:87
#2  0xb5526c96 in ?? () from /usr/lib/libasound.so.2
#3  0xb5526e4b in snd_pcm_wait () from /usr/lib/libasound.so.2
#4  0xb0067e92 in gst_alsasink_write(asink=0xd634f88, data=0xd78b3b8,
length=7520) at gstalsasink.c:865
#5  0xb0149d47 in audioringbuffer_thread_func (buf=0xafb211f0) at
gstaudiosink.c:244
#6  0xb715bb6f in ?? () from /lib/libglib-2.0.so.0
#7  0xb77fc955 in start_thread (arg=0xafaffb70) at pthread_create.c:300
#8  0xb7597e7e in clone ()
at ../sysdeps/unix/sysv/linux/i386/clone.S:130


As you can see, the segfault occurs in a thread without symbols. Will
it make a difference if I install each and every -dbg package indicated
by gdb (that's about a zillion-and-one packages), or am I facing a
corrupted stack?

I've now reverted to alsa-base from Squeeze, but that shows the same
problem. Is there another way that I can get more info from a core
dump, or should I just stick to downgrading/upgrading packages until
I've found the cause?


Thanks,
Arno