| Summary: | TDM crashes X | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Kris <krisgamrat> |
| Component: | tdebase | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | bugwatch, kb9vqf, krisgamrat |
| Priority: | P5 | ||
| Version: | R14.0.0 [Trinity] | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Attachments: |
debugger output from first crash handler
debugger output from second crash handler |
||
Created attachment 1190 [details]
debugger output from second crash handler
Confirming. There is some type of glib related threading error that affects both tdm_greeter and kdesktop_lock in the same way. Full backtrace: Program received signal SIGABRT, Aborted. [Switching to Thread 0xb5e19b70 (LWP 9854)] 0xb7702424 in __kernel_vsyscall () (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb6318781 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb631bbb2 in abort () from /lib/i686/cmov/libc.so.6 #3 0xb61c332f in g_assertion_message () from /lib/libglib-2.0.so.0 #4 0xb61c398d in g_assertion_message_expr () from /lib/libglib-2.0.so.0 #5 0xb619d348 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #6 0xb61a0fe8 in ?? () from /lib/libglib-2.0.so.0 #7 0xb61a11c8 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #8 0xb69b317e in TQEventLoop::processEvents (this=0x82c1fc0, flags=4) at kernel/qeventloop_x11_glib.cpp:280 #9 0xb69f55d0 in TQEventLoop::enterLoop (this=0x82c1fc0) at kernel/qeventloop.cpp:227 #10 0xb69f56ad in TQEventLoop::exec (this=0x82c1fc0) at kernel/qeventloop.cpp:174 #11 0xb6a6cfb3 in TQEventLoopThread::run (this=0xb5518578) at kernel/qthread.cpp:255 #12 0xb69d5eec in TQThreadInstance::start (_arg=0xb55185a4) at kernel/qthread_unix.cpp:129 #13 0xb612f955 in start_thread () from /lib/i686/cmov/libpthread.so.0 #14 0xb63ba1de in clone () from /lib/i686/cmov/libc.so.6 glib assertion that fires the SIGABRT: GLib:ERROR:/build/buildd-glib2.0_2.24.2-1-i386-AScyie/glib2.0-2.24.2/glib/gmain.c:1963:g_main_dispatch: assertion failed: (current->dispatching_sources == ¤t_source_link) I have traced this bug into glib, and do not yet have a workaround. Basically, under certain conditions glib can assign two different threads the same internal thread ID (!!). Once this behavior was narrowed down, I found a post from another developer effectively confirming this is present in glib itself: http://gtk.10911.n7.nabble.com/Glib-Gthread-unique-thread-id-question-td20975.html Out of curiosity, what versions of Debian have you seen this bug appear on? I have a Debian Squeeze laptop here that reproduces the bug with near 100% certainty, while I have never seen the bug appear on my Debian Wheezy testing workstations. The root cause of this crash was eventually traced into a call to pthread_getspecific() in glib's threading support. According to the pthread specification (http://pubs.opengroup.org/onlinepubs/009696799/functions/pthread_setspecific.html), "The effect of calling pthread_getspecific() or pthread_setspecific() with a key value not obtained from pthread_key_create() or after key has been deleted with pthread_key_delete() is undefined.". However, glib uses pthread_getspecific() to determine if a thread was newly created or not, meaning that on some systems (read: for some *allowed* thread interleavings and/or memory reclaimation/reuse strategies...) glib could retrieve the ID of a previously created thread and assign it to the newly created thread. This is in clear violation of the glib threading API documentation (https://developer.gnome.org/glib/2.31/glib-Threads.html), which states "This function will return a GThread even for threads that were not created by GLib (i.e. those created by other threading APIs). " The only feasible workaround is to use the glib thread creation functions, as the glib developers have taken special steps to ensure that a third party library cannot simply set the appropriate pthread data key to NULL after pthread_create has been called. Fix has been verified and has been committed to GIT in hashes c69c340 (Qt3) and 5faba37 (TQt3). Thanks for reporting! (In reply to comment #4) > Out of curiosity, what versions of Debian have you seen this bug appear on? I > have a Debian Squeeze laptop here that reproduces the bug with near 100% > certainty, while I have never seen the bug appear on my Debian Wheezy testing > workstations. Squeeze. Specifically, I believe I'm on 6.04, though I doubt that makes a difference. Since it's marked resolved, though, I doubt the version makes a difference any more. |
Created attachment 1189 [details] debugger output from first crash handler This bug is different from #1453. I have recently removed (and instructed apt to purge) all TDE packages for reinstallation to test another bug, and I now discover that TDM is causing Xorg to crash. First, Xorg starts with with the TDE crash handler (see attachment for debugger output). Closing this window allows the CTRL+ALT+DEL window to appear. Pressing CTRL+ALT+DEL causes a second crash handler to appear (will attach separately, it's only allowing one attachment here). Closing this brings back the CTRL+ALT+DEL window. Pressing the keys again brings a 3rd crash handler, but before I have a chance to get the debugger output, Xorg crashes completely. I tried really hard to '/etc/init.d/tdm-trinity restart' in hopes of getting the 3rd debugger output, but Xorg crashes too quickly.