| Summary: | Desktop locking crashs after resume from suspend to RAM [QSocketNotifier::setEnabled, PasswordDlg::reapVerify, PasswordDlg::handleVerify] | ||
|---|---|---|---|
| Product: | [Unmaintained] kscreensaver | Reporter: | Felix Lemke <hobbyblobby> |
| Component: | general | Assignee: | kscreensaver bugs tracking <kscreensaver-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | andresbajotierra, Carth_Onasi, cfox04, kdelibs-bugs, mail, michal.vyskocil, mitchell, n.massao, ossi, plasma-bugs, s.de.bie, steve |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Felix Lemke
2009-12-08 17:07:48 UTC
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. |