Summary: | kig crash on exit | ||
---|---|---|---|
Product: | [Applications] kig | Reporter: | Peter Volkov <torre_cremata> |
Component: | general | Assignee: | David E. Narvaez <david.narvaez> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | atalanttore, bakes, cfeck, david.narvaez, islamistina, javi.azuaga, jwelsh, leveillerems, mohnkhan, montez1, mouezapeter, polong, tikhonov-nikita, wangsuda2003 |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/kig/a8d1873368c5872b388b20f4e3a9f23bf7b57b12 | Version Fixed In: | 4.12.3 |
Sentry Crash Report: | |||
Attachments: |
proposed patch
New crash information added by DrKonqi Proposed patch: cancel construction before quit |
Description
Peter Volkov
2008-10-23 19:16:14 UTC
Aha, this bug is reproducible. I have not set point, I've just started kig, closed "Do you know?" window, then chosed move parallel tool (at the left border top tool) set red dot on the workspace and then pressed close button, said that I don't want to save anything and got crash! Yes, I can confirm it. I'll look at it ASAP, hopefully for KDE 4.1.3. *** Bug 176157 has been marked as a duplicate of this bug. *** *** Bug 180817 has been marked as a duplicate of this bug. *** *** Bug 196947 has been marked as a duplicate of this bug. *** *** Bug 184203 has been marked as a duplicate of this bug. *** *** Bug 226722 has been marked as a duplicate of this bug. *** *** Bug 212415 has been marked as a duplicate of this bug. *** Apparently, when I added several KDE packages to ubuntu, my system decided it is now ``kubuntu'', per the startup flash screen. Now, the kde software does not all work. HMM... Created attachment 51605 [details]
proposed patch
The bug is caused by ~KigPart being called while the nested event loop for the current mode is still running.
This patch works around that by disallowing the user to close the window while he is constructing something.
*** Bug 267036 has been marked as a duplicate of this bug. *** Created attachment 59165 [details]
New crash information added by DrKonqi
kig (v1.0) on KDE Platform 4.5.1 (KDE 4.5.1) using Qt 4.7.0
- What I was doing when the application crashed:
I started Kig for the first time, drawed some lines and tried out some buttons.
Lastly, I wanted to close Kig and did a click on X (close button), but the program didn't react and I clicked again and again on the close button until it crashed.
-- Backtrace (Reduced):
#6 QAction::setEnabled (this=0x10812e0, b=false) at kernel/qaction.cpp:1113
#7 0x00007f22dc8c9261 in KigMode::enableActions (this=0x109be60) at ../../kig/modes/mode.cc:30
#8 0x00007f22dc8cc98e in NormalMode::enableActions (this=0x10812e0) at ../../kig/modes/normal.cc:48
#9 0x00007f22dc90e151 in KigPart::setMode (this=0x1081920, m=0x0) at ../../kig/kig/kig_part.cpp:512
#10 0x00007f22dc90e33c in KigPart::runMode (this=0x1081920, m=0x130bb20) at ../../kig/kig/kig_part.cpp:678
This doesn't seem to be happening any more, so I'm closing this bug. Feel free to reopen if it appears again. The bug is still there. To reproduce: - start kig - klick on any construction tool in toolbar - close window Backtrace with today's master: Application: Kig (kig), signal: Segmentation fault [KCrash Handler] #7 0xb60cdb00 in QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::data (this=0x45454549) at ../../include/QtCore/../../../../git/Qt/frameworks/qt/src/corelib/tools/qscopedpointer.h:135 #8 0xb60cca43 in qGetPtrHelper<QScopedPointer<QObjectData> > (p=...) at ../../include/QtCore/../../../../git/Qt/frameworks/qt/src/corelib/global/qglobal.h:2434 #9 0xb60ccf1a in QAction::d_func (this=0x45454545) at /local/git/Qt/frameworks/qt/src/gui/kernel/qaction.h:67 #10 0xb60cb67b in QAction::setEnabled (this=0x45454545, b=false) at /local/git/Qt/frameworks/qt/src/gui/kernel/qaction.cpp:1113 #11 0xb21aefcd in KigMode::enableActions (this=0x8748608) at /local/git/KDE/edu/kig/modes/mode.cc:30 #12 0xb21b35f2 in NormalMode::enableActions (this=0x8748608) at /local/git/KDE/edu/kig/modes/normal.cc:48 #13 0xb220b539 in KigPart::setMode (this=0x87577a8, m=0x8748608) at /local/git/KDE/edu/kig/kig/kig_part.cpp:518 #14 0xb220c256 in KigPart::runMode (this=0x87577a8, m=0x87549c8) at /local/git/KDE/edu/kig/kig/kig_part.cpp:696 #15 0xb216af9c in ConstructibleAction::act (this=0x87bc6a0, d=...) at /local/git/KDE/edu/kig/misc/guiaction.cc:80 #16 0xb216b352 in KigGUIAction::slotActivated (this=0x87f4c88) at /local/git/KDE/edu/kig/misc/guiaction.cc:106 #17 0xb216ac44 in KigGUIAction::qt_static_metacall (_o=0x87f4c88, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xbffcca88) at /local/build/KDE/edu/kig/guiaction.moc:49 #18 0xb5a38e0e in QMetaObject::activate (sender=0x87f4c88, m=0xb6bf37a8, local_signal_index=1, argv=0xbffcca88) at /local/git/Qt/frameworks/qt/src/corelib/kernel/qobject.cpp:3547 #19 0xb60cc92a in QAction::triggered (this=0x87f4c88, _t1=false) at .moc/debug-shared/moc_qaction.cpp:277 #20 0xb60cbd69 in QAction::activate (this=0x87f4c88, event=QAction::Trigger) at /local/git/Qt/frameworks/qt/src/gui/kernel/qaction.cpp:1257 #21 0xb60ccf89 in QAction::trigger (this=0x87f4c88) at /local/git/Qt/frameworks/qt/src/gui/kernel/qaction.h:218 #22 0xb6641887 in QToolButton::nextCheckState (this=0x8841798) at /local/git/Qt/frameworks/qt/src/gui/widgets/qtoolbutton.cpp:1144 #23 0xb6548c26 in QAbstractButtonPrivate::click (this=0x8841a78) at /local/git/Qt/frameworks/qt/src/gui/widgets/qabstractbutton.cpp:530 #24 0xb654a0a7 in QAbstractButton::mouseReleaseEvent (this=0x8841798, e=0xbffcd324) at /local/git/Qt/frameworks/qt/src/gui/widgets/qabstractbutton.cpp:1123 #25 0xb66401c6 in QToolButton::mouseReleaseEvent (this=0x8841798, e=0xbffcd324) at /local/git/Qt/frameworks/qt/src/gui/widgets/qtoolbutton.cpp:718 #26 0xb613b01d in QWidget::event (this=0x8841798, event=0xbffcd324) at /local/git/Qt/frameworks/qt/src/gui/kernel/qwidget.cpp:8371 #27 0xb6549f18 in QAbstractButton::event (this=0x8841798, e=0xbffcd324) at /local/git/Qt/frameworks/qt/src/gui/widgets/qabstractbutton.cpp:1082 #28 0xb66418fc in QToolButton::event (this=0x8841798, event=0xbffcd324) at /local/git/Qt/frameworks/qt/src/gui/widgets/qtoolbutton.cpp:1160 #29 0xb60db280 in QApplicationPrivate::notify_helper (this=0x861b2a8, receiver=0x8841798, e=0xbffcd324) at /local/git/Qt/frameworks/qt/src/gui/kernel/qapplication.cpp:4551 #30 0xb60d93b1 in QApplication::notify (this=0xbffcdac4, receiver=0x8841798, e=0xbffcd324) at /local/git/Qt/frameworks/qt/src/gui/kernel/qapplication.cpp:4094 #31 0xb6e21a3a in KApplication::notify (this=0xbffcdac4, receiver=0x8841798, event=0xbffcd324) at /local/git/KDE/libs/kdelibs/kdeui/kernel/kapplication.cpp:311 #32 0xb5a1d0a6 in QCoreApplication::notifyInternal (this=0xbffcdac4, receiver=0x8841798, event=0xbffcd324) at /local/git/Qt/frameworks/qt/src/corelib/kernel/qcoreapplication.cpp:915 #33 0xb60ddc63 in QCoreApplication::sendSpontaneousEvent (receiver=0x8841798, event=0xbffcd324) at ../../include/QtCore/../../../../git/Qt/frameworks/qt/src/corelib/kernel/qcoreapplication.h:234 #34 0xb60d7b35 in QApplicationPrivate::sendMouseEvent (receiver=0x8841798, event=0xbffcd324, alienWidget=0x8841798, nativeWidget=0x88405f8, buttonDown=0xb6c124e0, lastMouseReceiver=..., spontaneous=true) at /local/git/Qt/frameworks/qt/src/gui/kernel/qapplication.cpp:3160 #35 0xb6172ced in QETWidget::translateMouseEvent (this=0x88405f8, event=0xbffcd7f0) at /local/git/Qt/frameworks/qt/src/gui/kernel/qapplication_x11.cpp:4502 #36 0xb616f886 in QApplication::x11ProcessEvent (this=0xbffcdac4, event=0xbffcd7f0) at /local/git/Qt/frameworks/qt/src/gui/kernel/qapplication_x11.cpp:3503 #37 0xb61a6461 in x11EventSourceDispatch (s=0x861ae28, callback=0, user_data=0x0) at /local/git/Qt/frameworks/qt/src/gui/kernel/qguieventdispatcher_glib.cpp:146 #38 0xb4c0a863 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #39 0xb4c0ac00 in ?? () from /usr/lib/libglib-2.0.so.0 #40 0xb4c0ace1 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #41 0xb5a54cfe in QEventDispatcherGlib::processEvents (this=0x860ed10, flags=...) at /local/git/Qt/frameworks/qt/src/corelib/kernel/qeventdispatcher_glib.cpp:424 #42 0xb61a67b6 in QGuiEventDispatcherGlib::processEvents (this=0x860ed10, flags=...) at /local/git/Qt/frameworks/qt/src/gui/kernel/qguieventdispatcher_glib.cpp:204 #43 0xb5a1a755 in QEventLoop::processEvents (this=0xbffcda6c, flags=...) at /local/git/Qt/frameworks/qt/src/corelib/kernel/qeventloop.cpp:149 #44 0xb5a1a8cd in QEventLoop::exec (this=0xbffcda6c, flags=...) at /local/git/Qt/frameworks/qt/src/corelib/kernel/qeventloop.cpp:204 #45 0xb5a1d73c in QCoreApplication::exec () at /local/git/Qt/frameworks/qt/src/corelib/kernel/qcoreapplication.cpp:1187 #46 0xb60d8796 in QApplication::exec () at /local/git/Qt/frameworks/qt/src/gui/kernel/qapplication.cpp:3812 #47 0x0804ecca in main (argc=1, argv=0xbffcdc14) at /local/git/KDE/edu/kig/kig/main.cpp:141 Sorry, I totally misread the instructions in the bug report, indeed it is still reproducible. I'm taking a look at it. Thanks! *** Bug 316603 has been marked as a duplicate of this bug. *** *** Bug 320665 has been marked as a duplicate of this bug. *** Created attachment 84935 [details]
Proposed patch: cancel construction before quit
I can confirm Christoph's patch works as described, but I don't think it's a good user experience. You try to quit the program, and the button responds but it doesn't quit. There's no indication that the construct mode has to be canceled first.
Here's an update of the patch that escapes the nested event loop before quitting by canceling the construction. It's definitely an abuse of queryClose(), and I don't understand the Kig code well enough to guarantee it will always work. In particular, is it possible for there to be more than two levels of nested event loops, i.e. some other mode invoked from within a construct mode? Still, it does solve this particular crash, and makes the program behave as the user expects.
I don't see another way to do it, short of getting rid of the event loop nesting altogether, which seems to be the root of the problem. Although, a halfway but reliable alternative would be to cancel the construction but return false from KigPart::queryClose(). That is, the first time you try to quit, it just cancels the mode; the second time it really quits.
Thanks Jacob, I tested your patch from https://git.reviewboard.kde.org/r/115604/ and it seems a far better workaround than mine :) Jacob, thanks for the patch. I am currently racing against deadlines but I will try to look at it in the next couple of days, yet in general my preferred solution would be a patch that eliminates the event loop nesting (because trying to exit the nested loops correctly is apparently impossible or at least I haven't found a way to do so), have you considered that option? Oh, I agree. I'd like to see the UI be more modeless in general, and flattening the event loop would be a prerequisite for that. But that looked like a bigger job than I care to bite off right now. So consider this a band-aid for a highly user-visible bug, in lieu of a grand rewrite that might never get done. Git commit a8d1873368c5872b388b20f4e3a9f23bf7b57b12 by Albert Astals Cid, on behalf of Jacob Welsh. Committed on 13/02/2014 at 21:54. Pushed by aacid into branch 'KDE/4.12'. Fix memory corruption on quit by canceling the active construct mode Acked by David Narváez FIXED-IN: 4.12.3 REVIEW: 115604 M +1 -19 kig/kig.cpp M +13 -0 kig/kig_part.cpp M +7 -0 kig/kig_part.h M +1 -1 modes/mode.cc http://commits.kde.org/kig/a8d1873368c5872b388b20f4e3a9f23bf7b57b12 |