Bug 368278

Summary: ksmserver crash takes down KDevelop while destroying Q_QGS_s_pKDirWatchSelf
Product: [Frameworks and Libraries] frameworks-kcoreaddons Reporter: Alexander Potashev <aspotashev>
Component: generalAssignee: Michael Pyne <mpyne>
Status: RESOLVED DUPLICATE    
Severity: crash CC: faure, kdelibs-bugs-null
Priority: NOR Keywords: drkonqi
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Alexander Potashev 2016-09-05 13:22:29 UTC 
Application: kdevelop (5.0.0)

Qt Version: 5.6.1
Frameworks Version: 5.25.0
Operating System: Linux 4.6.4-201.fc23.x86_64+debug x86_64
Distribution: "Fedora release 24 (Twenty Four)"

-- Information about the crash:
- What I was doing when the application crashed:
1. RMB in project tree -> Install
2. RMB in project tree -> Build (before Install finished)

- Unusual behavior I noticed:

KDE Plasma session crashed at the same moment with message "Could not start ksmserver. Check your installation."

-- Backtrace:
Application: KDevelop (kdevelop), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
29	  return SYSCALL_CANCEL (wait4, pid, stat_loc, options, NULL);
[Current thread is 1 (Thread 0x7f7764c23940 (LWP 25494))]

Thread 4 (Thread 0x7f77277fe700 (LWP 8311)):
#0  0x00007f77781e1bd0 in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f7777cabbc4 in QTWTF::TCMalloc_PageHeap::scavengerThread() (this=0x7f7777d97380 <QTWTF::pageheap_memory>) at /usr/src/debug/qtscript-opensource-src-5.6.1/src/3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:2359
#2  0x00007f7777cabc09 in QTWTF::TCMalloc_PageHeap::runScavengerThread(void*) (context=<optimized out>) at /usr/src/debug/qtscript-opensource-src-5.6.1/src/3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:1464
#3  0x00007f77781dc5ca in start_thread (arg=0x7f77277fe700) at pthread_create.c:333
#4  0x00007f777f0cbf6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 3 (Thread 0x7f7750af0700 (LWP 25502)):
#0  0x00007f77781e1f79 in pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x00007f777fcd7ff8 in QWaitCondition::wait(QMutex*, unsigned long) (time=1000, this=0x222f850) at thread/qwaitcondition_unix.cpp:126
#2  0x00007f777fcd7ff8 in QWaitCondition::wait(QMutex*, unsigned long) (time=1000, this=0x222f850) at thread/qwaitcondition_unix.cpp:134
#3  0x00007f777fcd7ff8 in QWaitCondition::wait(QMutex*, unsigned long) (this=<optimized out>, mutex=0x222eaf0, time=1000) at thread/qwaitcondition_unix.cpp:208
#4  0x00007f777d0de93d in KDevelop::DUChainPrivate::CleanupThread::run() () at /lib64/libKDevPlatformLanguage.so.10
#5  0x00007f777fcd799a in QThreadPrivate::start(void*) (arg=0x222ead0) at thread/qthread_unix.cpp:341
#6  0x00007f77781dc5ca in start_thread (arg=0x7f7750af0700) at pthread_create.c:333
#7  0x00007f777f0cbf6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 2 (Thread 0x7f775a4c1700 (LWP 25496)):
#0  0x00007f777f0c03ed in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f77758f8a06 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f774c003020, timeout=<optimized out>, context=0x7f774c000990) at gmain.c:4135
#2  0x00007f77758f8a06 in g_main_context_iterate (context=context@entry=0x7f774c000990, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3835
#3  0x00007f77758f8b1c in g_main_context_iteration (context=0x7f774c000990, may_block=may_block@entry=1) at gmain.c:3901
#4  0x00007f777fec524b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x7f774c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:419
#5  0x00007f777fe745ea in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7f775a4c0c40, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204
#6  0x00007f777fcd3343 in QThread::exec() (this=this@entry=0x7f7785d72060 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread.cpp:500
#7  0x00007f7785cfd559 in QDBusConnectionManager::run() (this=0x7f7785d72060 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at qdbusconnection.cpp:189
#8  0x00007f777fcd799a in QThreadPrivate::start(void*) (arg=0x7f7785d72060 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread_unix.cpp:341
#9  0x00007f77781dc5ca in start_thread (arg=0x7f775a4c1700) at pthread_create.c:333
#10 0x00007f777f0cbf6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 1 (Thread 0x7f7764c23940 (LWP 25494)):
[KCrash Handler]
#5  0x00007f7780c69b20 in QMap<QString, KDirWatchPrivate::Entry>::detach() (__m=std::memory_order_relaxed, this=#6  0x00007f7780c69b20 in QMap<QString, KDirWatchPrivate::Entry>::detach() (_q_value=#7  0x00007f7780c69b20 in QMap<QString, KDirWatchPrivate::Entry>::detach() (this=#8  0x00007f7780c69b20 in QMap<QString, KDirWatchPrivate::Entry>::detach() (this=#9  0x00007f7780c69b20 in QMap<QString, KDirWatchPrivate::Entry>::detach() (this=0x30) at /usr/include/qt5/QtCore/qmap.h:360
#10 0x00007f7780c64066 in KDirWatchPrivate::removeEntries(KDirWatch*) (this=0x30) at /usr/include/qt5/QtCore/qmap.h:548
#11 0x00007f7780c64066 in KDirWatchPrivate::removeEntries(KDirWatch*) (this=0x0, instance=instance@entry=0x7f7780ec60b0 <(anonymous namespace)::Q_QGS_s_pKDirWatchSelf::innerFunction()::holder>) at /usr/src/debug/kcoreaddons-5.25.0/src/lib/io/kdirwatch.cpp:1103
#12 0x00007f7780c6436f in KDirWatch::~KDirWatch() (this=0x7f7780ec60b0 <(anonymous namespace)::Q_QGS_s_pKDirWatchSelf::innerFunction()::holder>, __in_chrg=<optimized out>) at /usr/src/debug/kcoreaddons-5.25.0/src/lib/io/kdirwatch.cpp:1882
#13 0x00007f7780c64389 in (anonymous namespace)::Q_QGS_s_pKDirWatchSelf::Holder::~Holder() (this=<optimized out>, __in_chrg=<optimized out>) at /usr/src/debug/kcoreaddons-5.25.0/src/lib/io/kdirwatch.cpp:1846
#14 0x00007f777f0021e8 in __run_exit_handlers (status=status@entry=1, listp=0x7f777f3855d8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#15 0x00007f777f002235 in __GI_exit (status=status@entry=1) at exit.c:104
#16 0x00007f77673c1a7a in _IceDefaultIOErrorHandler (iceConn=<optimized out>) at error.c:603
#17 0x00007f77673c7b84 in IceFlush (iceConn=iceConn@entry=0x1bf2960) at misc.c:78
#18 0x00007f77671b5378 in SmcCloseConnection (smcConn=0x1c11740, count=count@entry=0, reasonMsgs=reasonMsgs@entry=0x0) at sm_client.c:305
#19 0x00007f775e0931a3 in QXcbSessionManager::~QXcbSessionManager() (this=0x1bca130, __in_chrg=<optimized out>) at qxcbsessionmanager.cpp:376
#20 0x00007f775e0931d9 in QXcbSessionManager::~QXcbSessionManager() (this=0x1bca130, __in_chrg=<optimized out>) at qxcbsessionmanager.cpp:379
#21 0x00007f77801a4c5d in QSessionManagerPrivate::~QSessionManagerPrivate() (this=0x1bf1700, __in_chrg=<optimized out>) at kernel/qsessionmanager.cpp:127
#22 0x00007f77801a4c79 in QSessionManagerPrivate::~QSessionManagerPrivate() (this=0x1bf1700, __in_chrg=<optimized out>) at kernel/qsessionmanager.cpp:129
#23 0x00007f777fea5647 in QObject::~QObject() (pointer=<optimized out>) at ../../src/corelib/tools/qscopedpointer.h:54
#24 0x00007f777fea5647 in QObject::~QObject() (this=0x1bef548, __in_chrg=<optimized out>) at ../../src/corelib/tools/qscopedpointer.h:101
#25 0x00007f777fea5647 in QObject::~QObject() (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qobject.cpp:893
#26 0x00007f77801a4d69 in QSessionManager::~QSessionManager() (this=0x1bef540, __in_chrg=<optimized out>) at kernel/qsessionmanager.cpp:138
#27 0x00007f77801a9c6b in QGuiApplication::~QGuiApplication() (this=0x7fff206d4160, __in_chrg=<optimized out>) at kernel/qguiapplication.cpp:602
#28 0x00007f77807066cf in QApplication::~QApplication() (this=0x7fff206d4160, __in_chrg=<optimized out>) at kernel/qapplication.cpp:820
#29 0x00000000004155bc in KDevelopApplication::~KDevelopApplication() ()
#30 0x000000000040f071 in main ()

Reported using DrKonqi
Comment 1 Milian Wolff 2016-09-05 13:58:03 UTC 
The backtrace indicates that you quit the application. Is that not what you did? The title of this bugreport says something completely different. Hm.... I rather think that this is a setup issue on your side
Comment 2 Alexander Potashev 2016-09-05 22:14:46 UTC 
ksmserver could crash first and make KDevelop exit.
Comment 3 Milian Wolff 2016-09-07 00:26:32 UTC 
right, but that would mean the bug lies elsewhere and there's not much we can do here. I'll re-assign this to KIO for now. David, if you know how to handle this, please let us know. I simply doubt KDevelop can do anything about this crash report.
Comment 4 Alexander Potashev 2016-09-07 08:33:35 UTC 
I could reproduce almost the same scenario another couple of times yesterday, namely:

1. Press F8 to build the current project,
2. Press F8 a few more times while still building,
3. Then I get the "Could not start ksmserver. Check your installation." message (and the whole session is taken down), KDevelop crashes with the same stacktrace.

KDirWatch is kcoreaddons, not kio.
Comment 5 Alexander Potashev 2016-09-07 08:34:42 UTC 
CCing David because he wrote the relevant thread safety code.
Comment 6 Michael Pyne 2016-09-08 03:30:59 UTC 
Looks like the d-ptr for KDirWatch gets reset (but not deleted!) by postRoutine_KDirWatch (which deletes the QFSWatcher but also deletes the KDirWatchPrivate!).

Later the KDirWatch's global destructor runs due to the Q_GLOBAL_STATIC entry's destruction, which checks its thread-local KDirWatchPrivate (stored in a QThreadStorage). But the values are inconsistent here, the QThreadStorage still has a KDirWatchPrivate (it was never deleted or reset), but the KDirWatch dtor tries to access that KDirWatchPrivate through its own d-ptr (already reset to nullptr...).

I'm not proficient with this code but it seems that either the d-ptr should /not/ be reset when removing the QFSWatcher, or the QThreadStorage for all the d-ptrs should *also* be reset when the d-ptr is, instead of the in-between we currently have.
Comment 7 Michael Pyne 2017-08-06 21:13:31 UTC 
I believe this is the same bug that RJVB fixed for other reasons in bug 381583, closing as a dupe of the more recent bug since that's where the fix was accounted for.

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