define "latest 3.5 branch fixes": does that include andreas kling's commit on tuesday of revision #571260 ?

Yes.

SVN commit 571782 by kling:

Delete all signal connections to a TaskContainer when marking it for deletion.

CCBUG: 132208


 M  +4 -0      taskcontainer.cpp  


--- branches/KDE/3.5/kdebase/kicker/taskbar/taskcontainer.cpp #571781:571782
@@ -1582,6 +1582,10 @@
 
 void TaskContainer::finish()
 {
+    // Disconnect all signal/slot connections to avoid triggering a popupMenu() call,
+    // whose event loop is the root of all (or at least much) evil. (kling)
+    disconnect();
+
     if (m_menu) {
         m_menu->close();
         m_menu->deleteLater();

Could you try again with this fix (#3)?

Either way, I'd be very interested in
a) Any way to reproduce this crash.
a) A complete valgrind trace. ;-)

Unfortunately it's not easily reproducible (or at least I didn't found out how to trigger it) and I do not have a scriptable vm I could run in the background so I'm sorry to deny both a). I have tried more than two dozen times to reproduce the crash and only by luck, I got a similar backtrace (of course I didn't notice, until looking at the first backtrace and so didn't save it :( ). It was some press action instead a mouse release event.


All I can give you is the list of apps I have open when logging out: Two KPDF instances, KMail, Kate, Konsole and in the tray KNemo, Kgpg, Klipper, Korganizer, Amarok and the tray volume applet.


I'll rebuild with your fix later today and see what the next days bring.

SVN commit 573071 by kling:

Seems we can't just disconnect() a TaskContainer, since that breaks a bunch of QGuardedPtrs.

CCBUG: 132208
CCMAIL: aseigo@kde.org
CCMAIL: maksim@kde.org


 M  +15 -2     taskcontainer.cpp  


--- branches/KDE/3.5/kdebase/kicker/taskbar/taskcontainer.cpp #573070:573071
@@ -1604,9 +1604,22 @@
 void TaskContainer::finish()
 {
     // Disconnect all signal/slot connections to avoid triggering a popupMenu() call,
-    // whose event loop is the root of all (or at least much) evil. (kling)
-    disconnect();
+    // whose event loop is the root of all (or at least much) evil.
+    // Unfortunately, we can't just do "disconnect()", because that gets us a bunch
+    // of dangling QGuardedPtr objects (most notably in QTipManager.) (kling)
 
+    animationTimer.disconnect();
+    dragSwitchTimer.disconnect();
+    attentionTimer.disconnect();
+
+    if (m_startup)
+        m_startup->disconnect(this);
+
+    for (Task::List::Iterator it = tasks.begin(); it != tasks.end(); ++it)
+    {
+        (*it)->disconnect(this);
+    }
+
     if (m_menu) {
         m_menu->close();
         m_menu->deleteLater();

Yesterday evening (Kicker 3.5 branch, without commit 574025 and 572463):


Using host libthread_db library "/lib/tls/libthread_db.so.1".
`system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols.
[Thread debugging using libthread_db enabled]
[New Thread -1232008480 (LWP 7927)]
[KCrash handler]
#6  TaskContainer::popupMenu (this=0x834a450, action=-1)
    at taskcontainer.cpp:1138
#7  0xb622ed5b in TaskContainer::performAction (this=0x834a450, action=0)
    at taskcontainer.cpp:966
#8  0xb622f18d in TaskContainer::mousePressEvent (this=0x834a450, e=0x0)
    at taskcontainer.cpp:894
#9  0xb718f8c2 in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3
#10 0xb70f1dbf in QApplication::internalNotify ()
   from /usr/qt/3/lib/libqt-mt.so.3
#11 0xb70f2175 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#12 0xb7763691 in KApplication::notify (this=0x80acdc0, receiver=0x834a450, 
    event=0xbfc704f0) at kapplication.cpp:550
#13 0xb70897f7 in QETWidget::translateMouseEvent ()
   from /usr/qt/3/lib/libqt-mt.so.3
#14 0xb70880ce in QApplication::x11ProcessEvent ()
   from /usr/qt/3/lib/libqt-mt.so.3
#15 0xb709c1e6 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#16 0xb71085b2 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#17 0xb7108506 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb70f0f6f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb67a7440 in kdemain (argc=-1, argv=0x80b15e0) at main.cpp:146
#20 0xb767f834 in kdeinitmain (argc=-1, argv=0xffffffff) at kicker_dummy.cpp:3
#21 0x0804ea5a in launch (argc=1, _name=0x80b370c "kicker", args=0x80b3713 "", 
    cwd=0x0, envc=0, envs=0x80b3717 "", reset_env=false, tty=0x0, 
    avoid_loops=false, 
    startup_id_str=0xffffffff <Address 0xffffffff out of bounds>)
    at kinit.cpp:639
#22 0x0804f23f in handle_launcher_request (sock=8) at kinit.cpp:1204
#23 0x0804f786 in handle_requests (waitForPid=0) at kinit.cpp:1407
#24 0x080500c3 in main (argc=3, argv=0xbfc71094, envp=0xffffffff)
    at kinit.cpp:1863
#25 0xb694ef21 in __libc_start_main () from /lib/tls/libc.so.6
#26 0x0804bcc1 in _start ()

SVN commit 576043 by kling:

Fixed double delete of TC's popup menu when TC disappears under the menu.

CCBUG: 132208
CCMAIL: timothee.lecomte@ens.fr


 M  +1 -4      taskcontainer.cpp  


--- branches/KDE/3.5/kdebase/kicker/taskbar/taskcontainer.cpp #576042:576043
@@ -1634,9 +1634,6 @@
         (*it)->disconnect(this);
     }
 
-    if (m_menu) {
+    if (m_menu)
         m_menu->close();
-        m_menu->deleteLater();
-        m_menu = 0;
-    }
 }

I dare say this is fixed now.

While I thought so, too, I experienced the crash as in comment seven again, yesterday evening.


With regards to bug 132576: Can't you just change it to wish, if you think it isn't a bug? I wouldn't have to say anything different and having to fill out half a dozen forms to file a bug is a pita.

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

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

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

Created attachment 20496 [details]
backtrace of the crash

Add a backtrace of a similar problem happened with KDE 3.5.6 in Kubuntu.
https://bugs.launchpad.net/ubuntu/+source/kdebase/+bug/108399

Isn't this a duplicate of http://bugs.kde.org/show_bug.cgi?id=98245
?

Also, forgive my ignorance - I'm new to this - from what I saw:
// Unfortunately, we can't just do "disconnect()", because that gets us a bunch 
// of dangling QGuardedPtr objects (most notably in QTipManager.)

Does this mean we leave connected stuff in QTipManager? If we do, and it still thinks the Task exists, what happens if it tries to display the tooltip? Could this be related to http://bugs.kde.org/show_bug.cgi?id=133386 ? The backtrace there shows the crash occurs at a call to KWin::icon() with an argument that reads tasks.last()->window(). Now, I'm not sure what that means, but what if we try to load the icon of a just-finished Task?

Why do you think it's a dupe? The backtraces differ slightly.

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

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

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

We love plasma!