Application: kwin_x11 (5.2.2) Qt Version: 5.4.1 Operating System: Linux 3.19.0-16-generic x86_64 Distribution: Ubuntu 15.04 -- Information about the crash: KWin sometimes crashes when I switch between windows. It can crash if I use Alt-Tab or if I switch with mouse. This is fresh installation of Kubuntu 15.04. Maybe it is important: this is a laptop with NVidia Optimus, :02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 1:00.0 3D controller: NVIDIA Corporation GK208M [GeForce GT 740M] (rev ff) I'm using NVidia binary drivers, version 346.59-0ubuntu1 from kubuntu repos. Maybe it's important: I'm also using my KWinscript: https://github.com/portnov/wacom-intuos-pro-scripts/blob/master/kde5/wacom-auto-profile/contents/code/main.js Maybe it contains some errors? If so, please explain how to find&fix the error. Anyway, crashing KWin because of wrong kwinscript is a bad idea. The crash can be reproduced sometimes. -- Backtrace: Application: KWin (kwin_x11), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7fa760fb0800 (LWP 364))] Thread 4 (Thread 0x7fa743558700 (LWP 404)): #0 0x00007fa760a83743 in select () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007fa75f2cd101 in qt_safe_select (nfds=15, fdread=fdread@entry=0x7fa738000a78, fdwrite=fdwrite@entry=0x7fa738000d08, fdexcept=fdexcept@entry=0x7fa738000f98, orig_timeout=orig_timeout@entry=0x0) at kernel/qcore_unix.cpp:75 #2 0x00007fa75f2cecd2 in select (timeout=0x0, exceptfds=0x7fa738000f98, writefds=0x7fa738000d08, readfds=0x7fa738000a78, nfds=<optimized out>, this=0x7fa7380008c0) at kernel/qeventdispatcher_unix.cpp:320 #3 QEventDispatcherUNIXPrivate::doSelect (this=this@entry=0x7fa7380008e0, flags=..., flags@entry=..., timeout=timeout@entry=0x0) at kernel/qeventdispatcher_unix.cpp:196 #4 0x00007fa75f2cf275 in QEventDispatcherUNIX::processEvents (this=0x7fa7380008c0, flags=...) at kernel/qeventdispatcher_unix.cpp:607 #5 0x00007fa75f2763e2 in QEventLoop::exec (this=this@entry=0x7fa743557da0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #6 0x00007fa75f035b44 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:503 #7 0x00007fa758ee8f65 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #8 0x00007fa75f03ab0e in QThreadPrivate::start (arg=0x1f8df00) at thread/qthread_unix.cpp:337 #9 0x00007fa7580b56aa in start_thread (arg=0x7fa743558700) at pthread_create.c:333 #10 0x00007fa760a8ceed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 3 (Thread 0x7fa7336ce700 (LWP 419)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007fa75de3f644 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5 #2 0x00007fa75de3f689 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5 #3 0x00007fa7580b56aa in start_thread (arg=0x7fa7336ce700) at pthread_create.c:333 #4 0x00007fa760a8ceed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 2 (Thread 0x7fa730e3f700 (LWP 1801)): #0 __libc_enable_asynccancel () at ../sysdeps/unix/sysv/linux/x86_64/cancellation.S:65 #1 0x00007fa760a83735 in select () at ../sysdeps/unix/syscall-template.S:81 #2 0x00007fa75f2cd101 in qt_safe_select (nfds=13, fdread=fdread@entry=0x7fa6a4074e48, fdwrite=fdwrite@entry=0x7fa6a40750d8, fdexcept=fdexcept@entry=0x7fa6a4075368, orig_timeout=orig_timeout@entry=0x0) at kernel/qcore_unix.cpp:75 #3 0x00007fa75f2cecd2 in select (timeout=0x0, exceptfds=0x7fa6a4075368, writefds=0x7fa6a40750d8, readfds=0x7fa6a4074e48, nfds=<optimized out>, this=0x7fa6a4051280) at kernel/qeventdispatcher_unix.cpp:320 #4 QEventDispatcherUNIXPrivate::doSelect (this=this@entry=0x7fa6a4074cb0, flags=..., flags@entry=..., timeout=timeout@entry=0x0) at kernel/qeventdispatcher_unix.cpp:196 #5 0x00007fa75f2cf275 in QEventDispatcherUNIX::processEvents (this=0x7fa6a4051280, flags=...) at kernel/qeventdispatcher_unix.cpp:607 #6 0x00007fa75f2763e2 in QEventLoop::exec (this=this@entry=0x7fa730e3eda0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #7 0x00007fa75f035b44 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:503 #8 0x00007fa758ee8f65 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #9 0x00007fa75f03ab0e in QThreadPrivate::start (arg=0x39a8fd0) at thread/qthread_unix.cpp:337 #10 0x00007fa7580b56aa in start_thread (arg=0x7fa730e3f700) at pthread_create.c:333 #11 0x00007fa760a8ceed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1 (Thread 0x7fa760fb0800 (LWP 364)): [KCrash Handler] #6 0x00007fa75de85060 in QScriptEngine::newVariant(QVariant const&) () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5 #7 0x00007fa76069b274 in KWin::AbstractScript::slotPendingDBusCall (this=0x2c87030, watcher=0x42bf5e0) at ../scripting/scripting.cpp:323 #8 0x00007fa7606eefcc in KWin::AbstractScript::qt_static_metacall (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>) at moc_scripting.cpp:104 #9 0x00007fa75f2a99c9 in QMetaObject::activate (sender=0x42bf5e0, signalOffset=<optimized out>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7ffe68a447b0) at kernel/qobject.cpp:3716 #10 0x00007fa75f2aa057 in QMetaObject::activate (sender=<optimized out>, m=m@entry=0x7fa76113d500 <QDBusPendingCallWatcher::staticMetaObject>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7ffe68a447b0) at kernel/qobject.cpp:3582 #11 0x00007fa761121a4f in QDBusPendingCallWatcher::finished (this=<optimized out>, _t1=0x42bf5e0) at .moc/moc_qdbuspendingcall.cpp:147 #12 0x00007fa761123155 in _q_finished (this=<optimized out>) at qdbuspendingcall.cpp:487 #13 QDBusPendingCallWatcher::qt_static_metacall (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>) at .moc/moc_qdbuspendingcall.cpp:79 #14 0x00007fa75f2aa73a in QObject::event (this=0x42bf5e0, e=<optimized out>) at kernel/qobject.cpp:1245 #15 0x00007fa75fb82b2c in QApplicationPrivate::notify_helper (this=0x1d8d120, receiver=0x42bf5e0, e=0x36fc8b0) at kernel/qapplication.cpp:3720 #16 0x00007fa75fb88000 in QApplication::notify (this=0x7ffe68a44d20, receiver=0x42bf5e0, e=0x36fc8b0) at kernel/qapplication.cpp:3503 #17 0x00007fa75f278c2b in QCoreApplication::notifyInternal (this=0x7ffe68a44d20, receiver=0x42bf5e0, event=event@entry=0x36fc8b0) at kernel/qcoreapplication.cpp:935 #18 0x00007fa75f27ac9b in sendEvent (event=0x36fc8b0, receiver=<optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:228 #19 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x1d7d2f0) at kernel/qcoreapplication.cpp:1552 #20 0x00007fa75f2cf112 in QEventDispatcherUNIX::processEvents (this=0x1dd0ca0, flags=flags@entry=...) at kernel/qeventdispatcher_unix.cpp:579 #21 0x00007fa74bd7496d in QUnixEventDispatcherQPA::processEvents (this=<optimized out>, flags=...) at eventdispatchers/qunixeventdispatcher.cpp:62 #22 0x00007fa75f2763e2 in QEventLoop::exec (this=this@entry=0x7ffe68a44c40, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #23 0x00007fa75f27e02c in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1188 #24 0x00007fa75f5bd31c in QGuiApplication::exec () at kernel/qguiapplication.cpp:1510 #25 0x00007fa75fb7e7a5 in QApplication::exec () at kernel/qapplication.cpp:2956 #26 0x00007fa760d548c3 in kdemain (argc=1, argv=0x7ffe68a44e78) at ../main_x11.cpp:294 #27 0x00007fa7609a6a40 in __libc_start_main (main=0x400790 <main(int, char**)>, argc=3, argv=0x7ffe68a44e78, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe68a44e68) at libc-start.c:289 #28 0x00000000004007c9 in _start () Reported using DrKonqi
The crash is in QtScript, I assume because var newProfile = profiles[client.resourceClass]; You could protect it var newProfile; if (client.resourceClass in profiles) newProfile = profiles[client.resourceClass]; I don't know enough about ECMA to say whether accessing an undefined hash key should throw an exception, but you're right that QtScript should not crash. Unfortunately I could not find a Qt bug report, so you may want to file one.
Hello. I tried to put try ... catch around all body of onFocus function. It did not help. For some reason, kwin crashes every time I close window with "yes/no/cancel" question about saving data from Krita. These steps always lead to kwin crash in my case: * Open Krita * Create new document * Draw any stroke * Press close button on Krita window. It will ask, if you want to save document. * Answer No * Dialog box and Krita window closes, and kwin crashes.
@Boud: any idea whether Krita does something "special" in the steps described in comment #2?
Same backtrace? Did you isolate your script? (ie. if it's perfectly reproducible, is it reproducible w/o your script as well?)
@Martin something special I could think of would be that two closing windows rapidly get focus (modal dialog -> closes -> main client -> closes) It will be krita because krita is handled by the script. The second client.resourceClass call could resolve to a dying/invalidated object and cause a memory corruption.
no, nothing special, though krita is a qtsingleapplication.
The problem seems to have something to do with script: if I remove the script, the problem does not reproduce.
Can you please try var className = client.resourceClass; withTabletProfile(function(tablet, oldProfile) { var newProfile = profiles[className]; ... I frankly cannot read the ECMA functor syntax, nor knows how it will act, but it looks a lot like some async dbus stuff is invoked what *may* result in async or threaded execution of your main slot - and the client object being gone in the meantime. You also may (no idea whether that'd be an improvement) want to include a timer here and check the workspace.activeClient class on timeout to update the wacom stuff. var updateDelay = new QTimer; updateDelay.singleShot = true; updateDelay.timeout.connect(onFocus); // TODO: function names should indicate what the function does, not what may or may not trigger it :-P workspace.clientActivated.connect(function(){updateDelay.start(250);}); // <- I hope i counted the braces correctly ;-)
PS: dbus is rather "slow" I/O - so you may - unrelated to this bug - want to cache the last active resourceClass and skip action if either it didn't change or old and new are not in the profile map (ie. you stay with the default profile)