Summary: | dragging an extender caused crash | ||
---|---|---|---|
Product: | [Unmaintained] plasma4 | Reporter: | Thomas Zander <zander> |
Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | aacid, alecm, andresbajotierra, aseigo, asraniel, juanantonio_garcia_01, konstvr, krase, notmart, olivier.delaune, rob |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Unspecified | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Thomas Zander
2008-12-23 21:44:04 UTC
What version of qt do you use? because this looks like an already patched bug of QT I'm using Qt 4.4, snapshot (I think I updated yesterday) either with qt-copy patches or a snapshot of 4.4.4? I don't have any patches. Just the plain QtSoftware repo of Qt4.4 branch. Are you saying that this is a Qt bug and that there is a patch available? Oh, maybe you are looking at the line numbers in my backtrace; they are offset some 30 lines due to me having a different license header in the files :( Thomas: yes, it -could- be the thing fixed in patch 0260 of qt-copy, but looking again at the backtrace i'm not really sure... i can reproduce this one; it appears there's something rather odd with the dragging of extenders, particularly if one moves the mouse too fast (easier to replicate with desktop effects on it seems) Ah, a fast moving mouse, so that's the trick to reproducing this. Now I can reproduce the problem myself: apparently moving the mouse very fast causes the item to stay at the same place. Releasing the mouse and initiating a new drag seems to cause the crash, while keeping the button pressed and moving the mouse back, and then slowly 'picking up' the item again doesn't crash plasma. I wonder if mouseMoveEvent even gets called in this situation. That still keeps the problem that for some people, moving the item off screen and opening a top level view on it takes some time making it look like it disappeared for a short while. For me this only takes a fraction of a second, but this needs to be faster. I'll going to do some valgrind profiling to see if there are any unnecessary function calls that can be removed or results that can be cached. I'm with my parents now for christmas and whatnot. I'll investigate this further next friday. I love it when people discover the steps to reproduce bugs :), apparently I'm not that quick usually when moving the mouse. related bug: http://bugs.kde.org/show_bug.cgi?id=178729 *** Bug 178777 has been marked as a duplicate of this bug. *** Bug 179405 seems to have a similar backtrace. I can reproduce this with kdebase4-workspace-4.1.87-5.1 from OpenSUSE KDE4:UNSTABLE and libqt4-4.4.3-29.1 from KDE:/Qt/openSUSE_11.1/ My backtrace looks like this: Thread 1 (Thread 0xb5163700 (LWP 25769)): [KCrash Handler] #6 0xb6d9e256 in QGraphicsScenePrivate::itemsAtPosition (this=0x8071078, screenPos=@0xbf7fcac4, scenePos=@0xbf7fcab0, widget=0x8583d28) at ../../src/corelib/kernel/qobject.h:438 #7 0xb6d9eb17 in QGraphicsScenePrivate::dispatchHoverEvent (this=0x8071078, hoverEvent=0xbf7fcb28) at graphicsview/qgraphicsscene.cpp:3371 #8 0xb6d9ec75 in QGraphicsScene::mouseReleaseEvent (this=0x8064638, mouseEvent=0xbf7fcf74) at graphicsview/qgraphicsscene.cpp:3613 #9 0xb6d9ef67 in QGraphicsScene::event (this=0x8064638, event=0xbf7fcf74) at graphicsview/qgraphicsscene.cpp:2966 #10 0xb67fc8fc in QApplicationPrivate::notify_helper (this=0x806e7a0, receiver=0x8064638, e=0xbf7fcf74) at kernel/qapplication.cpp:3803 #11 0xb680475e in QApplication::notify (this=0x805f900, receiver=0x8064638, e=0xbf7fcf74) at kernel/qapplication.cpp:3393 #12 0xb75e292d in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5 #13 0xb658c961 in QCoreApplication::notifyInternal (this=0x805f900, receiver=0x8064638, event=0xbf7fcf74) at kernel/qcoreapplication.cpp:587 #14 0xb6db3392 in QGraphicsView::mouseReleaseEvent (this=0x85791a8, event=0xbf7fd588) at ../../src/corelib/kernel/qcoreapplication.h:209 #15 0xb6854a62 in QWidget::event (this=0x85791a8, event=0xbf7fd588) at kernel/qwidget.cpp:7163 #16 0xb6b8aac3 in QFrame::event (this=0x85791a8, e=0xbf7fd588) at widgets/qframe.cpp:651 #17 0xb6c211ff in QAbstractScrollArea::viewportEvent (this=0x85791a8, e=0x8583d28) at widgets/qabstractscrollarea.cpp:943 #18 0xb6dae4df in QGraphicsView::viewportEvent (this=0x85791a8, event=0xbf7fd588) at graphicsview/qgraphicsview.cpp:2337 #19 0xb6c237a5 in QAbstractScrollAreaFilter::eventFilter (this=0x8598ed8, o=0x8583d28, e=0xbf7fd588) at widgets/qabstractscrollarea_p.h:96 #20 0xb658bb3a in QCoreApplicationPrivate::sendThroughObjectEventFilters (this=0x806e7a0, receiver=0x8583d28, event=0xbf7fd588) at kernel/qcoreapplication.cpp:694 #21 0xb67fc8da in QApplicationPrivate::notify_helper (this=0x806e7a0, receiver=0x8583d28, e=0xbf7fd588) at kernel/qapplication.cpp:3799 #22 0xb6805111 in QApplication::notify (this=0x805f900, receiver=0x8583d28, e=0xbf7fd588) at kernel/qapplication.cpp:3528 #23 0xb75e292d in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5 #24 0xb658c961 in QCoreApplication::notifyInternal (this=0x805f900, receiver=0x8583d28, event=0xbf7fd588) at kernel/qcoreapplication.cpp:587 #25 0xb680439e in QApplicationPrivate::sendMouseEvent (receiver=0x8583d28, event=0xbf7fd588, alienWidget=0x8583d28, nativeWidget=0x85791a8, buttonDown=0xb6fc8cb0, lastMouseReceiver=@0xb6fc8cb4) at ../../src/corelib/kernel/qcoreapplication.h:212 #26 0xb686e746 in QETWidget::translateMouseEvent (this=0x85791a8, event=0xbf7fdb6c) at kernel/qapplication_x11.cpp:4042 #27 0xb686daf5 in QApplication::x11ProcessEvent (this=0x805f900, event=0xbf7fdb6c) at kernel/qapplication_x11.cpp:3038 #28 0xb68960ba in x11EventSourceDispatch (s=0x8071ae8, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:142 #29 0xb55739a8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #30 0xb5577063 in ?? () from /usr/lib/libglib-2.0.so.0 #31 0xb5577221 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #32 0xb65b6fb8 in QEventDispatcherGlib::processEvents (this=0x8061a18, flags={i = -1082139352}) at kernel/qeventdispatcher_glib.cpp:319 #33 0xb68957b5 in QGuiEventDispatcherGlib::processEvents (this=0x8061a18, flags={i = -1082139304}) at kernel/qguieventdispatcher_glib.cpp:198 #34 0xb658b01a in QEventLoop::processEvents (this=0xbf7fddd0, flags={i = -1082139240}) at kernel/qeventloop.cpp:143 #35 0xb658b1da in QEventLoop::exec (this=0xbf7fddd0, flags={i = -1082139176}) at kernel/qeventloop.cpp:194 #36 0xb658d895 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:845 #37 0xb67fc777 in QApplication::exec () at kernel/qapplication.cpp:3331 #38 0xb7e83296 in kdemain (argc=1, argv=0xbf7fdf84) at /usr/src/debug/kdebase-workspace-4.1.87/plasma/shells/desktop/main.cpp:54 #39 0x08048782 in main (argc=6644797, argv=0xa4) at /usr/src/debug/kdebase-workspace-4.1.87/build/plasma/shells/desktop/plasma_qgv_dummy.cpp:3 This still happens in RC1 if the widgets are unlocked (if you use the steps I described in Bug 178777) Also reproducible using: Qt: 4.4.3 + qt-copy-patches-910240 KDE: 4.2.60 (KDE 4.2.60 (KDE 4.3 >= 20090106)) kdelibs svn rev. 911862 / kdebase svn rev. 911862 on ArchLinux x86_64 - Kernel 2.6.28 *** Bug 181786 has been marked as a duplicate of this bug. *** *** Bug 180653 has been marked as a duplicate of this bug. *** this is fixed in trunk as Rob changed how the dragging is done now. Any chance to get it into stable? Or at least make them non movable, that titlebar makes me want to move it each time i see it. The change in behavior is quite invasive: it's a huge patch, so I don't feel comfortable backporting to stable. As for making them non movable: it's a corner case in which this crash occurs (only when moving the LAST item over another window), it wouldn't be fair to completely remove this functionality for the people who use this feature without problems. +1 to Rob's analysis. I disagree with it being a corner case, each and every time i've tried to move a notification my plasma has crashed. @Albert: then you are suffering from a different problem then this bug. This is about the item losing mouse events when moving over another window after the popup has hidden, and crashing if you click them again after having lost those events. Do you by any change not have qt-copy with patches applied? Could you else open up a new bugreport with the backtrace? My backtrace is on comment #4 of bug 181786 that someone closed as duplicate of this one Oops, my fault *** Bug 192626 has been marked as a duplicate of this bug. *** *** Bug 181786 has been marked as a duplicate of this bug. *** *** Bug 193629 has been marked as a duplicate of this bug. *** |