Running QProcesses as workload of ThreadWeaver jobs

[David Faure]

On Saturday 22 October 2005 15:31, Adam Treat wrote:
> Hi Mirko,
> 
> I'm still investigating, but so far I haven't been able to come up with a 
> simple test case for why this fails in kdevelop4.  It doesn't seem to have 
> anything to do with how I'm using Threadweaver or QProcess... as I've 
> duplicated exactly what you're doing in your new test in kdevelop4 and it 
> still crashes with a backtrace that looks much like this:
> 
> #0  0xffffe410 in ?? ()
> #1  0x4294da08 in ?? ()
> #2  0x00000006 in ?? ()
> #3  0x000035c3 in ?? ()
> #4  0x41eda2c1 in raise () from /lib/tls/libc.so.6
> #5  0x41edbb75 in abort () from /lib/tls/libc.so.6
> #6  0x41cae6ec in qt_message_output (msgType=QtFatalMsg, buf=0x4294db80 
> "ASSERT failure in QEventDispatcherUNIX::registerTimer: \"timers cannot be 
> started from another thread\", file kernel/qeventdispatcher_unix.cpp, line 
> 383") at qglobal.cpp:1784
> #7  0x41caea59 in qFatal (msg=0x41d67ad0 "ASSERT failure in %s: \"%s\", file 
> %s, line %d") at qglobal.cpp:2000
> #8  0x41cae358 in qt_assert_x (where=0x41d8c158 
> "QEventDispatcherUNIX::registerTimer", what=0x41d8c128 "timers cannot be 
> started from another thread", file=0x41d8c104 
> "kernel/qeventdispatcher_unix.cpp", line=383) at qglobal.cpp:1559
> #9  0x41d5ceb4 in QEventDispatcherUNIX::registerTimer (this=0x805bc00, 
> timerId=7074, interval=20, obj=0x813c868) at qeventdispatcher_unix.cpp:381
> #10 0x41d2f7ce in QAbstractEventDispatcher::registerTimer (this=0x805bc00, 
> interval=20, object=0x813c868) at qabstracteventdispatcher.cpp:215
> #11 0x41d47181 in QObject::startTimer (this=0x813c868, interval=20) at 
> qobject.cpp:1339
> #12 0x41d50f1d in QTimer::start (this=0x813c868) at qtimer.cpp:175
> #13 0x41d50fe9 in QTimer::start (this=0x813c868, msec=20, sshot=true) at 
> qtimer.cpp:202
> #14 0x4101f200 in KCheckAccelerators::eventFilter () 
> from /home/manyoso/dev/kde/trunk/KDE/kdelibs4-snapshot-install/lib/libkdecore.so.4
> #15 0x4159d7a6 in QApplicationPrivate::notify_helper (this=0x80574f8, 
> receiver=0x429502e0, e=0x42950000) at qapplication.cpp:2944
> #16 0x4159c533 in QApplication::notify (this=0xbfffee40, receiver=0x429502e0, 
> e=0x42950000) at qapplication.cpp:2666
> #17 0x40f17e55 in KApplication::notify () 
> from /home/manyoso/dev/kde/trunk/KDE/kdelibs4-snapshot-install/lib/libkdecore.so.4
> #18 0x4126896b in QCoreApplication::sendEvent (receiver=0x429502e0, 
> event=0x42950000) at qcoreapplication.h:171
> #19 0x41d4790c in QObjectPrivate::setParent_helper (this=0x42e04b90, o=0x0) at 
> qobject.cpp:1674
> #20 0x41d45ec6 in ~QObject (this=0x42e049c0) at qobject.cpp:710
> #21 0x41d508f8 in ~QSocketNotifier (this=0x42e049c0) at 
> qsocketnotifier.cpp:160
> #22 0x41d253ac in QProcessPrivate::processStarted (this=0x838fd60) at 
> qprocess_unix.cpp:531
> #23 0x41cffbfb in QProcessPrivate::startupNotification (this=0x838fd60) at 
> qprocess.cpp:609
> #24 0x41d25892 in QProcessPrivate::waitForStarted (this=0x838fd60, 
> msecs=30000) at qprocess_unix.cpp:680
> #25 0x41d00559 in QProcess::waitForStarted (this=0x429502e0, msecs=30000) at 
> qprocess.cpp:967
> #26 0x41d006f7 in QProcess::waitForFinished (this=0x429502e0, msecs=30000) at 
> qprocess.cpp:1029
> #27 0x41cffed5 in ~QProcess (this=0x429502e0) at qprocess.cpp:662
> #28 0x42320d02 in ParseJob::run () 
> from /home/manyoso/dev/kde/trunk/KDE/kdelibs4-snapshot-install/lib/kde4/libkdevcpplanguagesupport.so
> #29 0x4021ea4d in ThreadWeaver::Job::execute () 
> from /home/manyoso/dev/kde/trunk/KDE/kdevelop/lib/weaver/.libs/libThreadWeaver.so.4
> #30 0x402202f2 in ThreadWeaver::Thread::run () 
> from /home/manyoso/dev/kde/trunk/KDE/kdevelop/lib/weaver/.libs/libThreadWeaver.so.4
> #31 0x41cb45d3 in QThreadPrivate::start (arg=0x838e268) at qthread_unix.cpp:83
> #32 0x41d9eaa7 in start_thread () from /lib/tls/libpthread.so.0
> #33 0x41f6cc2e in clone () from /lib/tls/libc.so.6
> (gdb) frame 0 
> #0  0xffffe410 in ?? ()
> 
> As you can see, it looks like this has to do with an eventFilter that is 
> installed somewhere by kdelibs that is sending the event across thread 
> boundaries...  That is what I'm guessing at least.  Not sure how this is 
> supposed to be fixed.

Does this help?

--- kcheckaccelerators.cpp      (revision 488546)
+++ kcheckaccelerators.cpp      (working copy)
@@ -109,6 +109,10 @@ bool KCheckAccelerators::eventFilter( QO
         break;
     case QEvent::ChildInserted:
     case QEvent::ChildRemoved:
+        // Only care about widgets; this also avoids starting the timer in other threads
+        if ( !static_cast<QChildEvent *>(e)->child()->isWidgetType() )
+            break;
+        // fall-through
     case QEvent::Resize:
     case QEvent::LayoutHint:
     case QEvent::WindowActivate:

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).