said Michele Calgaro: | On 2015/01/13 12:00 PM, dep wrote: | > (gdb) print *((int*)(0xda51f8)+2) $1 = 30334 | | That's good. It means the mutex is locked by thread 1 (LWP 30334). | | I actually noticed just now (my fault) that you do not have the debug | symbols installed for tdelibs, tdebase and tqt3. Can you install them, | exit gdb, reattach to the kdesktop process and run again the | thread apply all bt command?
(gdb) thread 2 [Switching to thread 2 (Thread 0x7f5c62de7700 (LWP 30339))] #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132 132 ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory. (gdb) frame 2 #2 0x00007f5c68011eba in __pthread_mutex_lock (mutex=0xda51f8) at pthread_mutex_lock.c:61 61 pthread_mutex_lock.c: No such file or directory. (gdb) p *(pthread_mutex_t*)0xda51f8 $1 = {__data = {__lock = 2, __count = 0, __owner = 30334, __nusers = 1, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\002\000\000\000\000\000\000\000~v\000\000\001", '\000' <repeats 26 times>, __align = 2} (gdb) thread apply all bt
Thread 2 (Thread 0x7f5c62de7700 (LWP 30339)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132 #1 0x00007f5c68012065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f5c68011eba in __pthread_mutex_lock (mutex=0xda51f8) at pthread_mutex_lock.c:61 #3 0x00007f5c6971f4ff in TQRecursiveMutexPrivate::lock (this=0xda51f0) at tools/qmutex_unix.cpp:251 #4 0x00007f5c69493655 in TQMutexLocker (m=0xd99660, this=<synthetic pointer>) at ../include/ntqmutex.h:102 #5 TQEventLoop::hasPendingEvents (this=<optimized out>) at kernel/qeventloop_x11_glib.cpp:633 #6 0x00007f5c694931d5 in TQEventLoop::gsourceCheck (this=0x7f5c5c001340, gs=<optimized out>) at kernel/qeventloop_x11_glib.cpp:507 #7 0x00007f5c69493243 in qt_gsource_check (source=0x7f5c5c002200) at kernel/qeventloop_x11_glib.cpp:105 #8 0x00007f5c65897b03 in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x00007f5c65897f96 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #10 0x00007f5c65898124 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x00007f5c69492b68 in TQEventLoop::processEvents (this=0x7f5c5c001340, flags=<optimized out>) at kernel/qeventloop_x11_glib.cpp:279 #12 0x00007f5c694c2319 in TQEventLoop::enterLoop (this=0x7f5c5c001340) at kernel/qeventloop.cpp:227 #13 0x00007f5c694c22a9 in TQEventLoop::exec (this=0x7f5c5c001340) at kernel/qeventloop.cpp:174 #14 0x00007f5c694a970d in TQThreadInstance::start (_arg=0xf4c5b8) at kernel/qthread_unix.cpp:142 #15 0x00007f5c658b99b5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #16 0x00007f5c6800fe9a in start_thread (arg=0x7f5c62de7700) at pthread_create.c:308 #17 0x00007f5c6cc942ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #18 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7f5c6d413780 (LWP 30334)): #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:93 #1 0x00007f5c6cc24f61 in _L_lock_10611 () at malloc.c:5249 #2 0x00007f5c6cc22c87 in __GI___libc_malloc (bytes=140034941749024) at malloc.c:2921 #3 0x00007f5c68fddded in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 ---Type <return> to continue, or q <return> to quit--- #4 0x00007f5c6972fdde in TQGArray::newData (this=<optimized out>) at tools/qgarray.cpp:819 #5 0x00007f5c6972fec7 in TQGArray::TQGArray (this=0x7fff3e582860) at tools/qgarray.cpp:118 #6 0x00007f5c69725809 in TQMemArray (this=0x7fff3e582860) at tools/ntqmemarray.h:61 #7 TQCString::TQCString (this=0x7fff3e582860, str=0x7f5c6d006c82 "1lockProcessWaiting()") at tools/qcstring.cpp:700 #8 0x00007f5c69515ccc in intSignature ( member=0x7f5c6d006c82 "1lockProcessWaiting()") at kernel/qsignal.cpp:134 #9 TQSignal::connect (this=0xdb3d70, receiver=0x7fff3e583670, member=0x7f5c6d006c82 "1lockProcessWaiting()") at kernel/qsignal.cpp:148 #10 0x00007f5c695218f4 in TQSingleShotTimer::start (this=0xdb3d20, msec=0, r=<optimized out>, m=<optimized out>) at kernel/qtimer.cpp:281 #11 0x00007f5c6cfbeccc in SaverEngine::slotLockProcessWaiting ( this=0x7fff3e583670) at /build/buildd/tdebase-trinity-14.0.0-r1865/kdesktop/lockeng.cc:548 #12 0x00007f5c6cfbcd93 in sigusr1_handler () at /build/buildd/tdebase-trinity-14.0.0-r1865/kdesktop/lockeng.cc:52 #13 <signal handler called> #14 0x00007f5c6cc2406a in __libc_calloc (n=2, elem_size=<optimized out>) at malloc.c:3291 #15 0x00007f5c6a1586ee in NETRArray (this=0xf402e0) at /build/buildd/tdelibs-trinity-14.0.0-r1231/tdecore/netwm.cpp:558 #16 NETWinInfoPrivate (this=0xf402c0) at /build/buildd/tdelibs-trinity-14.0.0-r1231/tdecore/netwm_p.h:122 #17 NETWinInfo::NETWinInfo (this=0x7fff3e582f60, display=0xd520d0, window=27263003, rootWindow=674, properties=0, role=<optimized out>) at /build/buildd/tdelibs-trinity-14.0.0-r1231/tdecore/netwm.cpp:2902 #18 0x00007f5c6a1b4922 in KWinModulePrivate::x11Event (this=0xdc5a80, ev=0x7fff3e583330)
at /build/buildd/tdelibs-trinity-14.0.0-r1231/tdecore/twinmodule.cpp:247 #19 0x00007f5c6a138ff0 in publicx11Event (e=0x7fff3e583330, this=<optimized out>)
at /build/buildd/tdelibs-trinity-14.0.0-r1231/tdecore/tdeapplication.cpp:1911 #20 TDEApplication::x11EventFilter (this=0xd50630, _event=0x7fff3e583330)
at /build/buildd/tdelibs-trinity-14.0.0-r1231/tdecore/tdeapplication.cpp:2189 #21 0x00007f5c6cfe5039 in KDesktopApp::x11EventFilter (this=0xd50630, xevent=0x7fff3e583330)
at /build/buildd/tdebase-trinity-14.0.0-r1865/kdesktop/kdesktopapp.cpp:90 #22 0x00007f5c6945b6f6 in TQApplication::x11ProcessEvent (this=0xd50630, event=0x7fff3e583330) at kernel/qapplication_x11.cpp:3435 #23 0x00007f5c69492d12 in TQEventLoop::processX11Events (this=0xda4be0) at kernel/qeventloop_x11_glib.cpp:353 #24 0x00007f5c694934f6 in TQEventLoop::gsourceDispatch (this=0xda4be0, gs=<optimized out>) at kernel/qeventloop_x11_glib.cpp:614 #25 0x00007f5c69493623 in qt_gsource_dispatch (source=0xda5c00, callback=<optimized out>, user_data=<optimized out>) at kernel/qeventloop_x11_glib.cpp:123 #26 0x00007f5c65897d13 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #27 0x00007f5c65898060 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #28 0x00007f5c65898124 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #29 0x00007f5c69492b68 in TQEventLoop::processEvents (this=0xda4be0, flags=<optimized out>) at kernel/qeventloop_x11_glib.cpp:279 #30 0x00007f5c694c2319 in TQEventLoop::enterLoop (this=0xda4be0) at kernel/qeventloop.cpp:227 #31 0x00007f5c694c22a9 in TQEventLoop::exec (this=0xda4be0) at kernel/qeventloop.cpp:174 #32 0x00007f5c6cf973ec in kdemain (argc=1, argv=0x7fff3e583dc8) at /build/buildd/tdebase-trinity-14.0.0-r1865/kdesktop/main.cc:293 #33 0x00000000004007a4 in main (argc=1, argv=0x7fff3e583dc8)
at /build/buildd/tdebase-trinity-14.0.0-r1865/obj-x86_64-linux-gnu/kdesktop/kdesktop_tdeinit_executable.cpp:2 #34 0x00007f5c6cbc176d in __libc_start_main ( main=0x400784 <main(int, char**)>, argc=1, ubp_av=0x7fff3e583dc8, ---Type <return> to continue, or q <return> to quit--- init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff3e583db8) at libc-start.c:226 #35 0x00000000004006c9 in _start () (gdb)
| That should provide more detailed information (i.e. line | numbers) about where each thread and frame is. | From a quick look at the current incomplete stack frame, thread 1 | (which is blocking thread 2) is blocked inside a malloc() call, which | as far as I can tell is usually a sign that the heap is corrupted | (perhaps a pointer deallocated twice). Now we are kind of stretching | to the limit of my knowledge as well, so I will need to guess/look up | what's the best way to go. | | By the way, when kdesktop_lock crashes do you have any crash report | window popping up in your system?
no. the only way i know it has happened is when i notice that the desktop program (xplanet set to refresh hourly) has stopped refreshing. nor does xerrors (or whatever it's called now) report anything.
| In the mean time, can you try the following things:
| 1) install the debug symbols as said above and provide the updated | stack frames
done, above.
| 2) kill kdesktop and run it again (or reboot your system, even | better). From CLI (outside TDE), run: | ps aux |grep kdesktop | Take note of the kdesktop_lock pid. Run: | gdb --pid=<kdesktop_lock pid> | After gdb attaches to the process, continue execution with: | c | At this stage kdesktop_lock should be running normally. Leave | everything running until kdesktop_lock crashes again. At this point | gdb should provide some info about the crash (perhaps a segmentation | fault - SIGSEGV). When it happens you should be able to get the stack | frame for kdesktop_lock (again thread apply all bt) since gdb is still | attached to the process. Do not exit gdb after that, not sure what | else we may need. All this is somehow experimental, if something | doesn't go to plan, please let me know.
will do. thanks very much for taking time to dig into this.