Re: [trinity-users] desktop crashing

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2015/01/13 12:00 PM, dep wrote: 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? 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? In the mean time, can you try the following things: 1) install the debug symbols as said above and provide the updated stack frames 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. Cheers Michele