Application: kscreenlocker (2.0) KDE Platform Version: 4.3.81 (KDE 4.3.81 (KDE 4.4 >= 20091204)) "release 2" Qt Version: 4.6.0 Operating System: Linux 2.6.31.5-0.1-default i686 Distribution: "openSUSE 11.2 (i586)" -- Information about the crash: After suspend to RAM and resume me screen is locked. The screensaver (asquiquarium) starts and before the password dialog comes, the screen locking program crashs (sorry, I don't know the right app name, because I have the german localized versio). After the crash I can't lock me screen. The crash can be reproduced some of the times. -- Backtrace: Application: KDE-Bildschirmsperre (kscreenlocker), signal: Segmentation fault [KCrash Handler] #6 0xb6cf73f1 in QSocketNotifier::setEnabled (this=0x82d2bd8, enable=false) at kernel/qsocketnotifier.cpp:293 #7 0x0805e9fc in PasswordDlg::reapVerify (this=0xbfe8f534) at /usr/src/debug/kdebase-workspace-4.3.81svn1058695/krunner/lock/lockdlg.cc:318 #8 0x0805ebd2 in PasswordDlg::handleVerify (this=0xbfe8f534) at /usr/src/debug/kdebase-workspace-4.3.81svn1058695/krunner/lock/lockdlg.cc:389 #9 0x0805fe14 in PasswordDlg::qt_metacall (this=0xbfe8f534, _c=InvokeMetaMethod, _id=78, _a=0xbfe8ece8) at /usr/src/debug/kdebase-workspace-4.3.81svn1058695/build/krunner/lock/lockdlg.moc:86 #10 0xb6ce119d in QMetaObject::metacall (object=0xbfe8f534, cl=InvokeMetaMethod, idx=78, argv=0xbfe8ece8) at kernel/qmetaobject.cpp:237 #11 0xb6ceff92 in QMetaObject::activate (sender=0x80912a8, m=0xb6df2550, local_signal_index=0, argv=0xbfe8ece8) at kernel/qobject.cpp:3275 #12 0xb6d43525 in QSocketNotifier::activated (this=0x80912a8, _t1=14) at .moc/release-shared/moc_qsocketnotifier.cpp:89 #13 0xb6cf757f in QSocketNotifier::event (this=0x80912a8, e=0xbfe8f144) at kernel/qsocketnotifier.cpp:317 #14 0xb62184ec in QApplicationPrivate::notify_helper (this=0x808c7e0, receiver=0x80912a8, e=0xbfe8f144) at kernel/qapplication.cpp:4253 #15 0xb621f300 in QApplication::notify (this=0xbfe90084, receiver=0x80912a8, e=0xbfe8f144) at kernel/qapplication.cpp:3663 #16 0xb74a5371 in KApplication::notify (this=0xbfe90084, receiver=0x80912a8, event=0xbfe8f144) at /usr/src/debug/kdelibs-4.3.81svn1058695/kdeui/kernel/kapplication.cpp:302 #17 0xb6cdbe2e in QCoreApplication::notifyInternal (this=0xbfe90084, receiver=0x80912a8, event=0xbfe8f144) at kernel/qcoreapplication.cpp:704 #18 0xb6d08dd8 in sendEvent (event=<value optimized out>, receiver=<value optimized out>) at kernel/qcoreapplication.h:215 #19 socketNotifierSourceDispatch (event=<value optimized out>, receiver=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:110 #20 0xb5ac34c2 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #21 0xb5ac6d98 in ?? () from /usr/lib/libglib-2.0.so.0 #22 0xb5ac6ebe in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #23 0xb6d089f1 in QEventDispatcherGlib::processEvents (this=0x808c7c0, flags=...) at kernel/qeventdispatcher_glib.cpp:407 #24 0xb62d7aea in QGuiEventDispatcherGlib::processEvents (this=0x808c7c0, flags=...) at kernel/qguieventdispatcher_glib.cpp:202 #25 0xb6cda49d in QEventLoop::processEvents (this=0xbfe8f3a0, flags=) at kernel/qeventloop.cpp:149 #26 0xb6cda8e9 in QEventLoop::exec (this=0xbfe8f3a0, flags=...) at kernel/qeventloop.cpp:201 #27 0xb6749c01 in QDialog::exec (this=0xbfe8f534) at dialogs/qdialog.cpp:530 #28 0x08054a9a in LockProcess::execDialog (this=0xbfe8ffa8, dlg=0xbfe8f534) at /usr/src/debug/kdebase-workspace-4.3.81svn1058695/krunner/lock/lockprocess.cc:1235 #29 0x0805b84a in LockProcess::checkPass (this=0xbfe8ffa8) at /usr/src/debug/kdebase-workspace-4.3.81svn1058695/krunner/lock/lockprocess.cc:1124 #30 0x0805c5b0 in LockProcess::x11Event (this=0xbfe8ffa8, event=0xbfe8fc4c) at /usr/src/debug/kdebase-workspace-4.3.81svn1058695/krunner/lock/lockprocess.cc:1305 #31 0xb74a49c7 in publicx11Event (e=<value optimized out>, this=<value optimized out>) at /usr/src/debug/kdelibs-4.3.81svn1058695/kdeui/kernel/kapplication.cpp:909 #32 KApplication::x11EventFilter (e=<value optimized out>, this=<value optimized out>) at /usr/src/debug/kdelibs-4.3.81svn1058695/kdeui/kernel/kapplication.cpp:959 #33 0xb6299d71 in qt_x11EventFilter (ev=0xbfe8fc4c) at kernel/qapplication_x11.cpp:399 #34 0xb62a975f in QApplication::x11ProcessEvent (this=0xbfe90084, event=0xbfe8fc4c) at kernel/qapplication_x11.cpp:3231 #35 0xb62d7f98 in x11EventSourceDispatch (s=0x808faf0, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:146 #36 0xb5ac34c2 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #37 0xb5ac6d98 in ?? () from /usr/lib/libglib-2.0.so.0 #38 0xb5ac6ebe in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #39 0xb6d089f1 in QEventDispatcherGlib::processEvents (this=0x808c7c0, flags=...) at kernel/qeventdispatcher_glib.cpp:407 #40 0xb62d7aea in QGuiEventDispatcherGlib::processEvents (this=0x808c7c0, flags=...) at kernel/qguieventdispatcher_glib.cpp:202 #41 0xb6cda49d in QEventLoop::processEvents (this=0xbfe8ff04, flags=) at kernel/qeventloop.cpp:149 #42 0xb6cda8e9 in QEventLoop::exec (this=0xbfe8ff04, flags=...) at kernel/qeventloop.cpp:201 #43 0xb6cdea60 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:981 #44 0xb6218594 in QApplication::exec () at kernel/qapplication.cpp:3572 #45 0x0806425b in main (argc=2, argv=0xbfe90214) at /usr/src/debug/kdebase-workspace-4.3.81svn1058695/krunner/lock/main.cc:173 Reported using DrKonqi
From bug 223220: -- Information about the crash: The password dialog doesn't show up. I pressed some random keys and mouse buttons but no respons. After a while i got my desktop back, without entering a password, and this crash report was shown.
*** Bug 223220 has been marked as a duplicate of this bug. ***
From bug 223281: -- Information about the crash: I put my display on laptop down, recover from sleep, work a few minutes, again suspend to RAM by closing laptop and quick recover, but there was no response, so I started to pressing some buttons (Esc, Enter, numbers, letters, mouse...) and get crash instead password window. -- Backtrace: #5 0x00007f8315397129 in QSocketNotifier::setEnabled (this=0x26721c0, enable=false) at kernel/qsocketnotifier.cpp:293 #6 0x0000000000418f41 in PasswordDlg::reapVerify (this=0x7fff18f46650) at /usr/src/debug/kdebase-workspace-4.3.90/krunner/lock/lockdlg.cc:318 #7 0x0000000000419288 in PasswordDlg::handleVerify (this=0x7fff18f46650) at /usr/src/debug/kdebase-workspace-4.3.90/krunner/lock/lockdlg.cc:389 #8 0x0000000000419364 in PasswordDlg::qt_metacall (this=0x7fff18f46650, _c=InvokeMetaMethod, _id=7471215, _a=<value optimized out>) at /usr/src/debug/kdebase-workspace-4.3.90/build/krunner/lock/lockdlg.moc:86 ...
*** Bug 223281 has been marked as a duplicate of this bug. ***
this crash makes totally no sense to me - it should be just impossible. :} maybe it is a bug in qt's glib mainloop integration. does the patch below help? diff --git a/krunner/lock/lockdlg.cc b/krunner/lock/lockdlg.cc --- a/krunner/lock/lockdlg.cc +++ b/krunner/lock/lockdlg.cc @@ -315,8 +315,13 @@ bool PasswordDlg::GRecvArr (char **ret) void PasswordDlg::reapVerify() { +if (!sNot) { + qDebug() << "the impossible happened: notified by no notifier ..."; + return; +} sNot->setEnabled( false ); sNot->deleteLater(); +sNot=0; ::close( sFd ); int status; ::waitpid( sPid, &status, 0 );
please also see the patch in bug 184465 comment 5.
*** Bug 223325 has been marked as a duplicate of this bug. ***
SVN commit 1082437 by ossi: waitpid() may get INTerRupted BUG: 184465 CCBUG: 217882 M +5 -1 lockdlg.cc WebSVN link: http://websvn.kde.org/?view=rev&revision=1082437
*** Bug 226449 has been marked as a duplicate of this bug. ***
bug 226449 comment 3 has a complete analysis of the problem
Well, possibly :-) My suggestion would be to try using a QMutex/QMutexLocker to guard the gplugStart and reapVerify functions. Since I forget if you can set a pointer to zero after calling deleteLater on it, add a bool value like sNotExists, guarded within the mutex -- or simply delete sNot directly at that point instead of using deleteLater, which would guarantee that the bool value is correct, in case something interrupts the event loop. I'll attach a patch; since I'm not running from compiled sources I'll need someone else to test it :-)
Scratch that -- I'll test it on my Gentoo box at work. Will reply as soon as possible.
a mutex is most definitely the wrong tool to fix a race in a single-threaded context. don't bother, i'll fix that tomorrow.
As it turns out -- my KDE 4.3.5 box at work does not suffer from this problem. Which is interesting, and makes me suspect this: http://websvn.kde.org/trunk/KDE/kdebase/workspace/krunner/lock/lockdlg.cc?r1=990095&r2=1028250 as the source of the problem -- which would mesh with my analysis of the code before. I'm going to try to reproduce this against 4.3 to verify the cause, then fix it. In the meantime, ossi, can you explain the reasoning for making it asynch?
I didn't realize it was single threaded. That makes things easier.
SVN commit 1089213 by mitchell: Fix race condition resulting in ability to crash the lock dialog or even unlock it without providing any password. BUG: 217882 M +10 -1 lockdlg.cc M +1 -0 lockdlg.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1089213
SVN commit 1089241 by mitchell: As requested, now that distros have confirmed the fix for crash/hang of lock dialog, backport to 4.4 branch. Pulled from r1089213. CCBUG: 217882 M +10 -1 lockdlg.cc M +1 -0 lockdlg.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1089241
*** Bug 226698 has been marked as a duplicate of this bug. ***
I had the same problem, but both occurred in screen fedora 18 as the shutdown of the session. I solved the problem by uninstalling and reinstalling kscreensaver again, and disabling all the possible options of the application. But I ran the screenserver.