Version: 4.0.83 (using Devel) Installed from: Compiled sources Compiler: gcc 4.3.1 OS: Linux When I choose to shut down my system, Plasma's Folderview crashed with this stack trace: Application: Plasma Workspace (<unknown>), signal SIGSEGV [Thread debugging using libthread_db enabled] [New Thread 0x2b5a7d83b030 (LWP 1708)] [New Thread 0x41005950 (LWP 1718)] [KCrash handler] #5 0x0000000000984140 in ?? () #6 0x00002aaaabaebe86 in ~FolderView (this=0x8806e0) at /usr/src/debug/kdebase-4.0.83/apps/plasma/applets/folderview/folderview.cpp:173 #7 0x00002b5a7300f17e in ~Containment (this=0x7e7660) at /usr/lib/qt4/include/QtCore/qalgorithms.h:352 #8 0x00002b5a806b7955 in ~DefaultDesktop (this=0x7e7660) at /usr/src/debug/kdebase-workspace-4.0.83/plasma/containments/desktop/desktop.cpp:83 #9 0x00002b5a7301a86e in ~Corona (this=0x708380) at /usr/lib/qt4/include/QtCore/qalgorithms.h:352 #10 0x00002b5a729d3827 in ~DesktopCorona (this=0x1ae0500) at /usr/src/debug/kdebase-workspace-4.0.83/plasma/plasma/desktopcorona.h:31 #11 0x00002b5a729deab6 in PlasmaApp::cleanup (this=0x61ed00) at /usr/src/debug/kdebase-workspace-4.0.83/plasma/plasma/plasmaapp.cpp:257 #12 0x00002b5a729e15b0 in PlasmaApp::qt_metacall (this=0x61ed00, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x7fff38302380) at /usr/src/debug/kdebase-workspace-4.0.83/build/plasma/plasma/plasmaapp.moc:79 #13 0x00002b5a73e95bf4 in QMetaObject::activate () from /usr/lib64/libQtCore.so.4 #14 0x00002b5a73e827ad in QCoreApplication::exec () from /usr/lib64/libQtCore.so.4 #15 0x00002b5a729d6983 in kdemain (argc=2, argv=0x7fff38302758) at /usr/src/debug/kdebase-workspace-4.0.83/plasma/plasma/main.cpp:54 #16 0x00002b5a72c0b32a in __libc_start_main () from /lib64/libc.so.6 #17 0x00000000004005c9 in _start ()
Can you comment out line 173 in folderview.cpp and recompile && install and see if it fixes please. It seems to me that KNewMenu should be deleted automatically as any QWidget but it's Sunday morning... Thanks in advance!
The prob is the KNewMenu* m_newMenu pointer since it will still point to the mem-address the KNewMenu* was on and didn't got set to NULL if the m_newMenu-instance got deleted. That in turn means, that each place that accessed the m_newMenu will probably deal with an invalid (aka deleted dangling) KNewMenu-pointer and crash. Following should fix it (QPointer sets m_newMenu to NULL if the KNewMenu* got deleted); Index: folderview.h =================================================================== --- folderview.h (revision 822884) +++ folderview.h (working copy) @@ -22,6 +22,7 @@ #include <QPersistentModelIndex> #include <QStyleOption> +#include <QPointer> #include <KActionCollection> @@ -133,7 +134,7 @@ bool m_viewScrolled; QString m_filterFiles; QFont m_font; - KNewMenu *m_newMenu; + QPointer<KNewMenu> m_newMenu; KActionCollection m_actionCollection; QVector<ViewItem> m_items; int m_columns;
fix committed with r823000+r823001 :)
*** Bug 164303 has been marked as a duplicate of this bug. ***
just to complete comment #2; within folderview.cpp the line; m_newMenu = new KNewMenu(&m_actionCollection, view(), "new_menu"); does create the m_newMenu-instance. The second argument is the QObject-parent. That means, that the m_newMenu is a child of the view() and will be deleted if the view() got deleted... an alternate fix to those from comment #2 would be to; - m_newMenu = new KNewMenu(&m_actionCollection, view(), "new_menu"); + m_newMenu = new KNewMenu(&m_actionCollection, this, "new_menu"); and then we could really just remove the delete from the destructor since then the m_newMenu would be child of our folderview and deleted if the folderview got deleted. But that would also change the parentWidget (from view() to this) and looking around within the folderview.cpp shows, that operation like e.g. copy, paste, del, etc. operate on the view(). So, the QPointer-"trick" seems to be the saver (as easier to be sure no new problems got introduced) solution :)
not adding any content here, but nice catch and fix, Sebastian =)