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.
--
dep
The shortest distance between you and playing great acoustic guitar:
the great new instructional DVDs from Marjorie Thompson,
available at www.MarjorieThompson.com