Bug 198075

Here using:

Qt: 4.5.2 (KDE-Qt git commit 46a247a2c9a8c0c4456a02f6a0922d859d88fe76
        Date:   Fri Jun 26 13:45:37 2009 +0200)
KDE: 4.3.60 (KDE 4.3.60 (KDE 4.4 >= 20090624))
kdelibs svn rev. 987857 / kdebase svn rev. 987857
on ArchLinux i686 - Kernel 2.6.30

I could reproduce the crash with the steps described.

Backtrace:

Application: Dolphin (dolphin), signal: Segmentation fault
[KCrash Handler]
#6  0xb6b5973f in QTabBarPrivate::_q_moveTabFinished (this=0xa236920, index=0) at widgets/qtabbar.cpp:1847
#7  0xb6b54c65 in QTabBarPrivate::refresh (this=0xa236920) at widgets/qtabbar.cpp:667
#8  0xb6b55917 in QTabBar::removeTab (this=0xa0e6a60, index=0) at widgets/qtabbar.cpp:897
#9  0x0806d0e0 in DolphinMainWindow::closeTab (this=0xa129918, index=0) at /home/kde-devel/kde/src/KDE/kdebase/apps/dolphin/src/dolphinmainwindow.cpp:905
#10 0x08071670 in DolphinMainWindow::qt_metacall (this=0xa129918, _c=QMetaObject::InvokeMetaMethod, _id=53, _a=0xbfa07ac8)
    at /home/kde-devel/kde/build/KDE/kdebase/apps/dolphin/src/dolphinmainwindow.moc:222
#11 0xb63ca892 in QMetaObject::activate (sender=0xa0e6a60, from_signal_index=42, to_signal_index=42, argv=0xbfa07ac8) at kernel/qobject.cpp:3112
#12 0xb63cac0a in QMetaObject::activate (sender=0xa0e6a60, m=0xb775b2b8, local_signal_index=5, argv=0xbfa07ac8) at kernel/qobject.cpp:3186
#13 0xb7666c53 in KTabBar::mouseMiddleClick (this=0xa0e6a60, _t1=0) at /home/kde-devel/kde/build/KDE/kdelibs/kdeui/ktabbar.moc:151
#14 0xb7667634 in KTabBar::mouseReleaseEvent (this=0xa0e6a60, event=0xbfa0821c) at /home/kde-devel/kde/src/KDE/kdelibs/kdeui/widgets/ktabbar.cpp:224
#15 0xb66ab350 in QWidget::event (this=0xa0e6a60, event=0xbfa0821c) at kernel/qwidget.cpp:7549
#16 0xb6b577b8 in QTabBar::event (this=0xa0e6a60, event=0xbfa0821c) at widgets/qtabbar.cpp:1453
#17 0xb664b00b in QApplicationPrivate::notify_helper (this=0xa059470, receiver=0xa0e6a60, e=0xbfa0821c) at kernel/qapplication.cpp:4056
#18 0xb6649d56 in QApplication::notify (this=0xbfa09b0c, receiver=0xa0e6a60, e=0xbfa0821c) at kernel/qapplication.cpp:3758
#19 0xb755bf7a in KApplication::notify (this=0xbfa09b0c, receiver=0xa0e6a60, event=0xbfa0821c) at /home/kde-devel/kde/src/KDE/kdelibs/kdeui/kernel/kapplication.cpp:302
#20 0xb63b1089 in QCoreApplication::notifyInternal (this=0xbfa09b0c, receiver=0xa0e6a60, event=0xbfa0821c) at kernel/qcoreapplication.cpp:610
#21 0xb664beb5 in QCoreApplication::sendSpontaneousEvent (receiver=0xa0e6a60, event=0xbfa0821c) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:216
#22 0xb664848c in QApplicationPrivate::sendMouseEvent (receiver=0xa0e6a60, event=0xbfa0821c, alienWidget=0xa0e6a60, nativeWidget=0xa129918, buttonDown=0xb70261a0, lastMouseReceiver=@0xb70261a4)
    at kernel/qapplication.cpp:2924
#23 0xb66cc3f4 in QETWidget::translateMouseEvent (this=0xa129918, event=0xbfa09790) at kernel/qapplication_x11.cpp:4409
#24 0xb66c90cc in QApplication::x11ProcessEvent (this=0xbfa09b0c, event=0xbfa09790) at kernel/qapplication_x11.cpp:3428
#25 0xb66fc5b4 in x11EventSourceDispatch (s=0xa05bd90, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:146
#26 0xb5bb6e08 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#27 0xb5bba370 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0
#28 0xb5bba4a3 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#29 0xb63e5922 in QEventDispatcherGlib::processEvents (this=0xa058fa8, flags={i = 36}) at kernel/qeventdispatcher_glib.cpp:327
#30 0xb66fcbda in QGuiEventDispatcherGlib::processEvents (this=0xa058fa8, flags={i = 36}) at kernel/qguieventdispatcher_glib.cpp:202
#31 0xb63ae667 in QEventLoop::processEvents (this=0xbfa09a5c, flags={i = 36}) at kernel/qeventloop.cpp:149
#32 0xb63ae7ac in QEventLoop::exec (this=0xbfa09a5c, flags={i = 0}) at kernel/qeventloop.cpp:201
#33 0xb63b1765 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:888
#34 0xb6649128 in QApplication::exec () at kernel/qapplication.cpp:3525
#35 0x0807a54f in main (argc=5, argv=0xbfa09ce4) at /home/kde-devel/kde/src/KDE/kdebase/apps/dolphin/src/main.cpp:94

I could not reproduce this first (with Qt 4.5.1), but I get this crash too after upgrading to Qt 4.5.2. Looking at QTabBar's code shows indeed that the line in QTabBarPrivate::_q_moveTabFinished() where the segfault occurs was added in Qt 4.5.2. I'll try to find out if this is a Qt bug or if something has to be changed in Dolphin (maybe it's somehow related to the signal-blocking in DolphinMainWindow::closeTab(int index)) when I find some time to do that.

It looks very much like a regression in Qt 4.5.2, caused by

http://qt.gitorious.org/qt/qt/commit/ea5991e330282a5b18301d653ccb5a7d960a7db5

Some observations:

1. The bug isn't related to closing the tab at all. If you comment out the lines in DolphinMainWindow that connect the middle-click signal to DolphinMainWindow::closeTab, the following happens: middle-clicking a tab activates it, and as soon as the mouse is moved by a single pixel after that, a segfault occurs in the same line in QTabBarPrivate::_q_moveTabFinished.

2. Reading the Qt source showed me a funny workaround: before middle-clicking a tab, use the new "move tabs by drag&drop" feature just once, and the crash is not reproducible any more.

I'll try to analyse this further, I think this might become a bit showstopping if distros start shipping KDE 4.3 with Qt 4.5.2 :-(

Created attachment 34899 [details]
My unsuccessful attempt to come up with a Qt-only testcase

The obvious patch for Qt (which fixes the crash for me) would be

--- a/src/gui/widgets/qtabbar.cpp
+++ b/src/gui/widgets/qtabbar.cpp
@@ -1844,7 +1844,8 @@ void QTabBarPrivate::_q_moveTabFinished(int index)
     Q_Q(QTabBar);
     bool cleanup = (pressedIndex == index) || (pressedIndex == -1) || !validIndex(index);
     if (animations.isEmpty() && cleanup) {
-        movingTab->setVisible(false); // We might not get a mouse release
+        if (movingTab)
+            movingTab->setVisible(false); // We might not get a mouse release
         for (int i = 0; i < tabList.count(); ++i) {
             tabList[i].dragOffset = 0;
         }

However, I could not come up with a Qt-only test case so far :-( I've tried a modified version of QTabBar which handles middle-clicks (see attachment), but I can't get it to crash:

1. If I choose to close tabs on middle-click, I never get to the point where Dolphin segfaults because pressedIndex is -1 in QTabBarPrivate::refresh() (see frame #7 in Daríos backtrace), so the function in frame #6 is not called. In the Dolphin case, pressedIndex seems to be the index of the middle-clicked tab.

2. If I remove the connection between the middle-click signal and the closeTab() slot in Dolphin, I can get a crash (as described in my previous comment) when middle-clicking a tab and then moving the mouse:

#6  0xb6c00131 in QTabBarPrivate::_q_moveTabFinished (this=0x9c14c68, index=0) at widgets/qtabbar.cpp:1848
#7  0xb6c04d7c in QTabBar::mouseMoveEvent (this=0x9c0e660, event=0xbfb30da8) at widgets/qtabbar.cpp:1725
#8  0xb768d1a6 in KTabBar::mouseMoveEvent (this=0x9c0e660, event=0xbfb30da8) at /home/kde-devel/kde/src/KDE/kdelibs/kdeui/widgets/ktabbar.cpp:181
#9  0xb671e85f in QWidget::event (this=0x9c0e660, event=0xbfb30da8) at kernel/qwidget.cpp:7534
#10 0xb6c035d1 in QTabBar::event (this=0x9c0e660, event=0xbfb30da8) at widgets/qtabbar.cpp:1453

If I do the corresponding thing in my test case and choose to only select tabs on middle-click, no crash happens. The reason is that a mouse move causes a HoverMove event which is handled inside QTabBar::event(), such that it never gets further than frame #10 (see above). In the Dolphin case, we also get HoverMove events usually, but when moving the mouse after middle-clicking a tab, a single MouseMove event is received which is forwarded to QWidget::event() (frame #9). I don't understand why - according to the Qt docs, a widget should not receive MouseMove events if the Qt::WA_Hover attribute is set (which seems to be the case here).

Maybe something odd is going on inside KTabBar. It seems that some further analysis is needed (I don't know if the Qt people would be willing to apply the patch above if the crash is not reproducible in a Qt-only program).

This crash seems to be related to the commit

http://websvn.kde.org:80/?view=rev&revision=936670

which restored the old "move tabs with middle mouse button" feature. I'll CC Urs because he committed that change.

Since then, the "press middle mouse button" event is intercepted in 

void KTabBar::mousePressEvent( QMouseEvent *event ),

but the "release mouse button" event isn't in 

void KTabBar::mouseReleaseEvent( QMouseEvent *event )

unless the mouse has been moved between press and release (because only then d->mMiddleMouseTabMoveInProgress is true), but I haven't fully understood yet what exactly leads to the crash then. Somehow QTabBar's and KTabBar's tab move code don't work together well, but I'm not sure if the mistake is in Qt 4.5.2 or on the KDE side.

*** Bug 199843 has been marked as a duplicate of this bug. ***

SVN commit 997506 by freininghaus:

Fix a crash when middle-clicking a tab in a KTabBar which has the
movable attribute set if Qt 4.5.2 or later is used. The problem was
that a faked mouse event was sent to QTabBar when pressing the middle
mouse button, but not when releasing it.

BUG: 198075


 M  +5 -0      ktabbar.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=997506

SVN commit 997509 by freininghaus:

Fix a crash when middle-clicking a tab in a KTabBar which has the
movable attribute set if Qt 4.5.2 or later is used. The problem was
that a faked mouse event was sent to QTabBar when pressing the middle
mouse button, but not when releasing it.

Fix will be in KDE 4.3.0.

CCBUG: 198075


 M  +5 -0      ktabbar.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=997509

*** Bug 200720 has been marked as a duplicate of this bug. ***