Siggi Langauf <[EMAIL PROTECTED]> writes: > Hi Brian, > > On Mon, 10 Jan 2005, Brian Nelson wrote: > >> Recently, pornview has been going limp whenever it is closed. I >> obtained the following backtrace: >> >> Program received signal SIG32, Real-time event 32. >> [Switching to Thread -1303675984 (LWP 25137)] >> 0xffffe410 in __kernel_vsyscall () >> (gdb) bt >> #0 0xffffe410 in __kernel_vsyscall () >> #1 0xb7a2c1b1 in ___newselect_nocancel () from >> /lib/tls/i686/cmov/libc.so.6 >> #2 0xb78c6e92 in _XPollfdCacheDel () from /usr/X11R6/lib/libX11.so.6 >> #3 0xb78c7e01 in _XRead () from /usr/X11R6/lib/libX11.so.6 >> #4 0xb78c7a54 in _XReadEvents () from /usr/X11R6/lib/libX11.so.6 >> #5 0xb78b8d20 in XNextEvent () from /usr/X11R6/lib/libX11.so.6 >> #6 0x0807a33f in gtk_xine_get_type () >> #7 0xb7aa1ca3 in start_thread () from >> /lib/tls/i686/cmov/libpthread.so.0 >> #8 0xb7a329ba in clone () from /lib/tls/i686/cmov/libc.so.6 >> (gdb) >> >> >> Do you think this is a bug in libxine1? > > I can't tell from that backtrace. > SIG32 is just an internal signal (used by the pthread implementation in > libpthread, IIRC), which is perfectly normal operation. > So you should always switch SIG32 handling off in GCC if you want to debug > a xine-lib related crash.
Oops. I sent the wrong backtrace. This is the real one: (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7aa541e in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb78e6286 in _XUnregisterFilter () from /usr/X11R6/lib/libX11.so.6 #3 0xb78c992e in _XReply () from /usr/X11R6/lib/libX11.so.6 #4 0xb78c4da4 in XSync () from /usr/X11R6/lib/libX11.so.6 #5 0xb5f3d308 in _x_alphablend_free () from /usr/lib/xine/plugins/1.0.0/xineplug_vo_out_xv.so #6 0x08268068 in ?? () #7 0x00000000 in ?? () #8 0x00000050 in ?? () #9 0x00000000 in ?? () #10 0xb7b04228 in ?? () from /usr/lib/libxine.so.1 #11 0x0826b648 in ?? () #12 0x081813f8 in ?? () #13 0xb7adac19 in _x_vo_new_port () from /usr/lib/libxine.so.1 #14 0x00000000 in ?? () #15 0x080ba224 in ?? () #16 0x081813f8 in ?? () #17 0xb7ad3b29 in xine_close_video_driver () from /usr/lib/libxine.so.1 #18 0x0826b648 in ?? () #19 0x0807aa44 in event_listener () Previous frame inner to this frame (corrupt stack?) > What you're looking for is either a SIGSEGV or a SIGBUS or _maybe_ a > SIGILL. (Note however, that SIGILL also happens on normal xine startup > when it's probing for various extensions of your processor's > instruction set...) When I say it "goes limp," I mean it hangs. :) It never actually segfaults or anything. The above backtrace is what I get when I interrupt the process during the hang. An strace shows it stuck in a futex() call... > Additionally, you'd need a debugging version of libxine to get really > meaningful stack traces. Only in rare cases does the non-debugging version > produce enough trace to be helpful... OK. I'll do that when I get a chance... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
