Summary: | Crash while running idle | ||
---|---|---|---|
Product: | [Unmaintained] kopete | Reporter: | Malte S. Stretz <mss> |
Component: | general | Assignee: | Kopete Developers <kopete-bugs-null> |
Status: | RESOLVED WORKSFORME | ||
Severity: | crash | CC: | nathan |
Priority: | NOR | ||
Version: | 0.8.0 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Malte S. Stretz
2004-01-30 01:04:30 UTC
Kopete just did it again, no backtrace this time. It just went away while I sat in front of my screen. I think some ICQ users of whom I still had chat windows open went online. Sorry but that still does not give us any hint. Try running it in valgrind and make sure you compiled at least kopete with --enable-debug=full and no hyperspeed optimizations. And btw, if you look into your backtrace you can clearly see that the last few calls (#12 up to #1) are all the way kdelibs and not Kopete code. Maybe try changing your iconset, disable icon effects and/or compile kdelibs with debug as well. Needless to say I have never seen such a crash. Also my Kopete is now running for about 8 hours without a hitch. My whole KDE is compile with full debug and just -O2 optimizations. My Inconset is Crystal SVG. So nothing weird here. And I don't even know what an IconEffect is ;-) I'm not even sure that the crash a few minutes ago was the same as Dr. Konqi stayed quiet. Kopete just closed itself. Nor that this is related to ICQ in any way -- ICQ is the only protocol I was chatting on, but I'm also logged in to two Jabber accounts and AIM. As this crash or whatever it is happens just once in a blue moon, I don't really want to keep Kopete running under valgrind all the time... Subject: Re: [Kopete-devel] Crash while running idle
On Monday 02 February 2004 21:47, Malte S.Stretz wrote:
> As this crash or whatever it is happens just once in a blue moon, I don't
> really want to keep Kopete running under valgrind all the time...
What *might* help is running Kopete in gdb, which doesn't slow down, but
occasionally produces better backtraces than DrKonqi. Your odds are small,
but it's the best I can think of.
Ok, it just happened again. A different backtrace this time, but you know what? I had a chat window open to a friend, ICQ contact. And he went offline. I'll keep Kopete running under valgrind now :) (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...[New Thread 16384 (LWP 7402)] [New Thread 32769 (LWP 9988)] 0x419bf40b in waitpid () from /lib/libpthread.so.0 #0 0x419bf40b in waitpid () from /lib/libpthread.so.0 #1 0x41109c8c in __JCR_LIST__ () from /usr/kde/cvs/lib/libkdecore.so.4 #2 0x419be1b3 in __pthread_sighandler () from /lib/libpthread.so.0 #3 <signal handler called> #4 0x4141ae0e in QObject::activate_signal(QConnectionList*, QUObject*) () from /usr/qt/3/lib/libqt-mt.so.3 #5 0x4141ac74 in QObject::activate_signal(int) () from /usr/qt/3/lib/libqt-mt.so.3 #6 0x41747e3b in QTimer::timeout() () from /usr/qt/3/lib/libqt-mt.so.3 #7 0x4143c212 in QTimer::event(QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #8 0x413c0075 in QApplication::internalNotify(QObject*, QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #9 0x413bf465 in QApplication::notify(QObject*, QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #10 0x40fcbdd5 in KApplication::notify(QObject*, QEvent*) () from /usr/kde/cvs/lib/libkdecore.so.4 #11 0x413af73d in QEventLoop::activateTimers() () from /usr/qt/3/lib/libqt-mt.so.3 #12 0x4136be9a in QEventLoop::processEvents(unsigned) () from /usr/qt/3/lib/libqt-mt.so.3 #13 0x413d1e76 in QEventLoop::enterLoop() () from /usr/qt/3/lib/libqt-mt.so.3 #14 0x413d1d18 in QEventLoop::exec() () from /usr/qt/3/lib/libqt-mt.so.3 #15 0x413c02c1 in QApplication::exec() () from /usr/qt/3/lib/libqt-mt.so.3 #16 0x0806516b in KIconLoader::unknown() () #17 0x41b2fdcc in __libc_start_main () from /lib/libc.so.6 And that backtrace is completely useless because all it says is "qt is idling in its event loop". Stefan, I *know* that backtrace isn't very useful, but it's at least a data point, isn't it? I hope that I'll find out why Kopete does this to me, until then I can just report "hey, it did it again" and try to find any pattern in the behaviour. > but it's at least a data point, isn't it?
Unfortunately no, the qt event loop is executed that often, you cannot say "it happens between function XYZ and signal ABC being emitted". Also the last backtrace contains no reference to kopete so there's not even a hint where things started to go wrong inside of kopete.
So far all we have is two backtraces and both of them don't show a crash in kopete but rather outside of kopete code.
Should we reassign this bug to kconfig? At least that's the last kde part the backtrace ends in. For what it's worth, I just tested the theory of ICQ contact chat window open and ICQ contact goes offline. No crash in 0.8.0. I haven't encountered this one again for some time now, maybe it got fixed in between. Feel free to close it to get the bug count down... okie dokie. Thanks Malte. :) Be sure to reopen if you can reliably reproduce. *** Bug 75805 has been marked as a duplicate of this bug. *** |