Summary: | plasma crashed on closing an applet | ||
---|---|---|---|
Product: | [Plasma] plasma4 | Reporter: | christopher v <legal-system> |
Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | CC: | valir |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
christopher v
2008-02-08 17:43:00 UTC
I'm using KDE 4.0.1 from official openSUSE 10.3 package repository. can you install the debug packages and try this again so we get a full backtrace? thanks! =) you can reproduce it by enlarging one icon as big as the screen is and then move it a bit around and then try to close it and your desktop will crash too. i dont know how to install the debug system *** Bug 157158 has been marked as a duplicate of this bug. *** changed summary to reflect the prob. According to the backtrace from bug #157158 the reason may the assert in; bool Containment::sceneEventFilter(QGraphicsItem *watched, QEvent *event) { ... Q_ASSERT(applet!=0); ... } and if final aka non-debug packages are installed and the assert fails, it may also result in a crash. So, maybe a fix may look like; Index: containment.cpp =================================================================== --- containment.cpp (revision 773254) +++ containment.cpp (working copy) @@ -819,7 +819,7 @@ // Otherwise we're watching something we shouldn't be... //kDebug() << "got sceneEvent"; Q_ASSERT(applet!=0); - if (!d->applets.contains(applet)) { + if (!applet || !d->applets.contains(applet)) { return false; } Though I've no idea why a (!d->applets.contains(NULL)) shouldn't work... maybe bug #157476 is related though it seems we have at least 2 independent crash-cases here :-/ Christoph: since you compiled from sources, I would suggest to use the -DCMAKE_BUILD_TYPE switch here to build at least kdelibs and kdebase with debug enabled what allows to produce more useful backtraces. So, something like e.g. cmake -DCMAKE_INSTALL_PREFIX=$KDEDIR -DCMAKE_BUILD_TYPE=debugfull /path/to/source For a quit intro how to do it using packages provided by a distributor you may also like to see http://bugs.kde.org/show_bug.cgi?id=157599#c4 Thanks in advance :) thx sebastian, im using official packages from openSUSE 10.3 actually. It just says compiled by source because this is another bug from this bug report machine,-) i choosed suse rpms but it dont work when you choose recent KDE version as well,-) anyway, ill try my best to get some backtrace or something. i installed some debug packages, reproduced the crash and i hope this helps you: [?1034hUsing host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 0xb575a6f0 (LWP 5827)] [New Thread 0xb3aa7b90 (LWP 5830)] 0xffffe410 in __kernel_vsyscall () [Current thread is 0 (LWP 5827)] Thread 2 (Thread 0xb3aa7b90 (LWP 5830)): #0 0xffffe410 in __kernel_vsyscall () #1 0xb726d566 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb72c39e8 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4 #3 0xb3f645f4 in RenderThread::run () from /usr/lib/kde4/plasma_containment_desktop.so #4 0xb72c3417 in QThreadPrivate::start () from /usr/lib/libQtCore.so.4 #5 0xb7269192 in start_thread () from /lib/libpthread.so.0 #6 0xb671802e in clone () from /lib/libc.so.6 Thread 1 (Thread 0xb575a6f0 (LWP 5827)): #0 0xffffe410 in __kernel_vsyscall () #1 0xb66e38d6 in nanosleep () from /lib/libc.so.6 #2 0xb66e36b7 in sleep () from /lib/libc.so.6 #3 0xb79f9849 in ?? () from /usr/lib/libkdeui.so.5 #4 0x00000001 in ?? () #5 0x00000000 in ?? () #0 0xffffe410 in __kernel_vsyscall () same bug: [?1034hUsing host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 0xb577a6f0 (LWP 7549)] [New Thread 0xb3ac7b90 (LWP 7550)] [KCrash handler] #6 0xb689544e in __dynamic_cast () from /usr/lib/libstdc++.so.6 #7 0xb7ee8bd8 in Plasma::Phase::timerEvent () from /usr/lib/libplasma.so.1 #8 0xb73964d4 in QObject::event () from /usr/lib/libQtCore.so.4 #9 0xb6c5e09d in QApplicationPrivate::notify_helper () from /usr/lib/libQtGui.so.4 #10 0xb6c64239 in QApplication::notify () from /usr/lib/libQtGui.so.4 #11 0xb79bc65d in KApplication::notify () from /usr/lib/libkdeui.so.5 #12 0xb738790b in QCoreApplication::notifyInternal () from /usr/lib/libQtCore.so.4 #13 0xb73abad4 in QTimerInfoList::activateTimers () from /usr/lib/libQtCore.so.4 #14 0xb73a9110 in timerSourceDispatch () from /usr/lib/libQtCore.so.4 #15 0xb64a55d6 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #16 0xb64a8972 in ?? () from /usr/lib/libglib-2.0.so.0 #17 0x0806a898 in ?? () #18 0x00000000 in ?? () #0 0xffffe410 in __kernel_vsyscall () same bug again: [?1034hUsing host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 0xb57606f0 (LWP 8564)] [New Thread 0xb3aadb90 (LWP 8565)] [KCrash handler] #6 0xb687b44e in __dynamic_cast () from /usr/lib/libstdc++.so.6 #7 0xb7ecebd8 in Plasma::Phase::timerEvent () from /usr/lib/libplasma.so.1 #8 0xb737c4d4 in QObject::event () from /usr/lib/libQtCore.so.4 #9 0xb6c4409d in QApplicationPrivate::notify_helper () from /usr/lib/libQtGui.so.4 #10 0xb6c4a239 in QApplication::notify () from /usr/lib/libQtGui.so.4 #11 0xb79a265d in KApplication::notify () from /usr/lib/libkdeui.so.5 #12 0xb736d90b in QCoreApplication::notifyInternal () from /usr/lib/libQtCore.so.4 #13 0xb7391ad4 in QTimerInfoList::activateTimers () from /usr/lib/libQtCore.so.4 #14 0xb738f110 in timerSourceDispatch () from /usr/lib/libQtCore.so.4 #15 0xb648b5d6 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #16 0xb648e972 in ?? () from /usr/lib/libglib-2.0.so.0 #17 0x0806a898 in ?? () #18 0x00000000 in ?? () #0 0xffffe410 in __kernel_vsyscall () Thanks for the additional input christopher :) So let's go step by step; * comment #c10 is imho a duplicate of bug #156944 or the related case discovered during a code-review where we did run into a div-by-zero. Both cases are fixed with 4.0.2 * comment #c11 and comment #c12 are imho related to bug #157476 which is a duplicate of bug #157647 . Also the crash happens on a similar situation, that is if an applet got removed what somehow increases the possibility that this report is a duplicate of #157647 by even more percent. So, all in all, let's mark this report as duplicate of the other then even if this report was created before the other since the other report contains an even more detailed backtrace. Now I wouldn't wonder if all the crashes are at the end a duplicate of bug #156944 and therefore already fixed in trunk and in the upcoming 4.0.2. Well, let's wait an see :) Thank you very much for the feedback! p.s. if you don't agree about the duplicate-factor, please reopen. Thanks in advance. *** This bug has been marked as a duplicate of 157647 *** nothing much to add here other than: great work Sebastian to get this one sorted out. always tricky when it's multiple bugs, fixed in trunk and backtraces that don't have full debug symbols =) |