Bug 357040 - Dolphin crashes with SIGSEGV because it prematurely destroys a QThread that is subsequently still used
Summary: Dolphin crashes with SIGSEGV because it prematurely destroys a QThread that i...
Status: RESOLVED DUPLICATE of bug 351485
Alias: None
Product: dolphin
Classification: Applications
Component: view-engine: general (show other bugs)
Version: 15.08.3
Platform: Debian unstable Linux
: NOR crash
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-22 13:26 UTC by jm.ouwerkerk
Modified: 2016-10-25 10:43 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jm.ouwerkerk 2015-12-22 13:26:46 UTC
Happens nearly but not quite every time in VirtualBox.

Dolphin version: 15.08

Reproducible: Sometimes

Steps to Reproduce:
1. Open Dolphin
2. Right click a directory
3. Move the mouse pointer towards Properties.

Actual Results:  
Dolphin crashes with a SIGSEGV.  qDebug statements point out that it happens because a QThread is being used that's already destroyed. Additionally if you trigger this from gdb it can lock up your session (prevent it from responding to mouse clicks, and keyboard input).

Expected Results:  
I'd expect the properties dialog of the directory to come up.

Fun fact: if you trigger this from gdb, which gives you a breakpoint at the crash site, you lock up the entire session because it becomes entirely unresponsive to input beyond mouse pointer movement.  No keyboard, no focus switching no... nothing except pointer movement.

Unfortunately Ctrl+Alt+F2 and so on don't work in virtualbox so a workaround is necessary to trigger this safely. Using SSH and the following command:
DISPLAY:0 gdb dolphin

I got this backtrace at the point of the segfault:

[New Thread 0x7fffd65db700 (LWP 908)]
QThread: Destroyed while thread is still running

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd65db700 (LWP 908)]
0x00007ffff2620843 in QThreadStorageData::finish(void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
(gdb) bt
#0  0x00007ffff2620843 in QThreadStorageData::finish(void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#1  0x00007ffff2621a25 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#2  0x00007ffff262289f in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#3  0x00007fffef10e284 in start_thread (arg=0x7fffd65db700) at pthread_create.c:333
#4  0x00007ffff784c74d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Comment 1 jm.ouwerkerk 2015-12-22 13:37:20 UTC
A better backtrace obtained the same way (ssh into the VM, execute DISPLAY:0 gdb dolphin)

[New Thread 0x7fffd6619700 (LWP 1121)]
QThread: Destroyed while thread is still running

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd6619700 (LWP 1121)]
QThreadStorageData::finish (p=p@entry=0xf8) at thread/qthreadstorage.cpp:169
169     thread/qthreadstorage.cpp: No such file or directory.
(gdb) bt
#0  QThreadStorageData::finish (p=p@entry=0xf8) at thread/qthreadstorage.cpp:169
#1  0x00007ffff2621a25 in QThreadPrivate::finish (arg=arg@entry=0x9a7d30) at thread/qthread_unix.cpp:351
#2  0x00007ffff262289f in __pthread_cleanup_class::~__pthread_cleanup_class (this=<synthetic pointer>, __in_chrg=<optimized out>) at /usr/include/pthread.h:563
#3  QThreadPrivate::start (arg=0x9a7d30) at thread/qthread_unix.cpp:290
#4  0x00007fffef10e284 in start_thread (arg=0x7fffd6619700) at pthread_create.c:333
#5  0x00007ffff784c74d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Comment 2 jm.ouwerkerk 2015-12-22 13:38:40 UTC
Qt version: 5.5.1
Comment 3 Elvis Angelaccio 2016-10-25 10:43:32 UTC

*** This bug has been marked as a duplicate of bug 351485 ***