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.
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...)
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...
HTH,
Siggi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
