Version: 0.10 (using KDE 3.4.0, Gentoo) Compiler: gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) OS: Linux (i686) release 2.6.10-gentoo-r7 If I log into an IRC server and join a channel, after several minutes of sending lines of text Kopete crashes. The only pattern I can see is that it crashes when I send several lines of text one after the other and nobody is speaking. It doesn't crash if I just leave it running, or send the odd line of chat to the channel. I compiled it with debugging support, but the backtrace still didn't contain anything useful. I definately saw kopete being compiled with "-g" (although -O2 was also used). If anyone has any suggestions about how I can make a more useful backtrace, I'll give it a go :)
Try to run the program under the valgrind tool. The magic command is something like: valgrind --tool=addrcheck --num-callers=20 -- kopete --nofork and return the interesting parts of the output.
On Sunday 06 March 2005 8:49 pm, James wrote: > I compiled it with debugging support, but the backtrace still didn't > contain anything useful. I definately saw kopete being compiled with "-g" > (although -O2 was also used). If you had at least -g, then the backtrace in the KCrashGuard should be at least a bit useful. Next time it crashes paste the backtrace in here.
Created attachment 10139 [details] Output from running kopete through valgrind This is the output from Kopete run through valgrind. I connected to an IRC network, the Jabber network and also tried to connect to the Yahoo IM network (but that didn't seem to work). I then tried to crash Kopete using things that usually make it die. Typing lots seems to do it. It didn't, but I suspect valgrind is doing something? I typed lots of junk text to myself into an empty channel, sent a private message to myself from another client and generally held a conversation with myself :-) There was nobody on Jabber that I knew to talk to, so that just sat idle. The Yahoo client remained in the "Connecting" state. Program ran for about 20 minutes before I quit it correctly. Having never seen a valgrind output before, it looks like memory is being free()'d that shouldn't be. Backtraces don't provide anything meaningful. Kopete is compiled with debugging, and hasn't been stripped but KCrashguard always tells me the backtrace is of no use.
It seems there is a stack corruption because the first valgrind entries say that there are some memory free in some code where it's impossible. see by 0x34E518EF: IRCUserContact::~IRCUserContact() (ksparser.cpp:39) Can you try to run valgrind once again with the memcheck tool instead ? I wonder if this could be related to "contact living chat session" bug :?
I have just enabled coredumps in my shell, and run kopete with the '--nofork --nocrashhandler' options. In this instance, KOpete crashed when I received a Yahoo IM chat and I clicked "ignore" in the notification bubble. This crash is different to the other ones, but is the only one where the backtraces make any sense. Here is the output. If you want the (very large - 10m) corefiles, just ask and I'll put them on the web. Core was generated by `kopete --nofork --nocrashhandler'. Program terminated with signal 11, Segmentation fault. #0 0x4007de59 in ?? () (gdb) bt #0 0x4007de59 in ?? () #1 0x0807527f in KopeteSystemTray::addBalloon() (this=0x824ee68) at systemtray.cpp:244 #2 0x080750e8 in KopeteSystemTray::slotEventDone(Kopete::MessageEvent*) (this=0x824ee68, event=0x83ab8a0) at systemtray.cpp:220 #3 0x08075de3 in KopeteSystemTray::qt_invoke(int, QUObject*) (this=0x824ee68, _id=63, _o=0xbfffd030) at systemtray.moc:121 #4 0x4e7bf107 in ?? () #5 0x0824ee68 in ?? () #6 0x0000003f in ?? () (gdb)
Created attachment 10151 [details] Output from running kopete through valgrind with the "memcheck" tool This is the output from running Kopete through valgrind's memcheck tool. I loaded the program, connected it to jabber, held a conversation and after around ten minutes of running, quit the program correctly.
This bug is known and I wonder if it was solved or not ? This is due to a reference being destroyed when it shouldn't. This bug is not related with IRC anyway.
I also am having a problem that appears to be similar - kopete crashes (occasionally) when I open a new chat with someone...either from the notification balloon or from the list. Oddly enough - I am also running Gentoo...it may be due to one of the patches that they apply. I'll try to get a stack trace to post - I didn't compile kopete with debugging enabled, so I'll need to recompile it...
Here is the backtrace that I was able to get - looks somewhat useful - but I don't know if it's all the way useful. To get this, I compiled kopete and kdelibs with debug options turned on... (gdb) bt #0 0xb6c0bd91 in QObject::disconnect () from /usr/qt/3/lib/libqt-mt.so.3 #1 0xb47dd372 in ?? () #2 0x08565940 in ?? () #3 0xb47f59ce in ?? () #4 0x08619780 in ?? () #5 0xb47f59b4 in ?? () #6 0x00000001 in ?? () #7 0xb47f59cd in ?? () #8 0xb47f59b4 in ?? () #9 0xb47f98fc in ?? () #10 0x08619780 in ?? () #11 0x08942590 in ?? () #12 0x00000028 in ?? () #13 0x080f9368 in ?? () #14 0xb7f34ece in Kopete::ChatSession::view (this=0x8942590, canCreate=69, requestedPlugin=@0x87a7e58) at kopetemessagemanager.cpp:429 #15 0xb7f3511d in Kopete::Contact::execute (this=0xbfffe0b0) at kopetecontact.cpp:465 #16 0xb7f35154 in Kopete::MetaContact::execute (this=0x504c5445) at kopetemetacontact.cpp:343 #17 0x080acd4f in KopeteMetaContactLVI::execute (this=0x848e1b8) at kopetemetacontactlvi.cpp:499 #18 0x08083c3c in KopeteContactListView::slotExecuted (this=0x82b91e8, ---Type <return> to continue, or q <return> to quit--- item=0x848e1e0, p=@0x87a7e58) at kopetecontactlistview.cpp:802 #19 0x0808c289 in KopeteContactListView::qt_invoke (this=0x82b91e8, _id=135162212, _o=0xbfffe230) at kopetecontactlistview.moc:219 #20 0xb6c0dda4 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #21 0xb748aee0 in KListView::executed (this=0x82b91e8, t0=0x504c5445, t1=@0x504c5445, t2=1347179589) at klistview.moc:360 #22 0xb748afd3 in KListView::emitExecute (this=0x82b91e8, item=0x848e1e0, pos=@0xbfffe518, c=0) at klistview.cpp:687 #23 0xb748b080 in KListView::slotMouseButtonClicked (this=0x504c5445, btn=1, item=0x0, pos=@0x504c5445, c=1347179589) at klistview.cpp:889 #24 0xb7569782 in KListView::qt_invoke (this=0x82b91e8, _id=-1073748932, _o=0xbfffe410) at klistview.moc:567 #25 0x0809c343 in Kopete::UI::ListView::ListView::qt_invoke (this=0x82b91e8, _id=94, _o=0xbfffe410) at kopetelistview.moc:98 #26 0x0808bfb4 in KopeteContactListView::qt_invoke (this=0x82b91e8, _id=94, _o=0xbfffe410) at kopetecontactlistview.moc:247 #27 0xb6c0dda4 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #28 0xb6f7d224 in QListView::mouseButtonClicked () from /usr/qt/3/lib/libqt-mt.so.3 #29 0xb6d003b2 in QListView::contentsMouseReleaseEventEx () from /usr/qt/3/lib/libqt-mt.so.3 #30 0xb6d00c64 in QListView::contentsMouseReleaseEvent () from /usr/qt/3/lib/libqt-mt.so.3 ---Type <return> to continue, or q <return> to quit--- #31 0xb752a3f0 in KListView::contentsMouseReleaseEvent (this=0x82b91e8, e=0xbfffe6e0) at klistview.cpp:863 #32 0xb6d2a545 in QScrollView::viewportMouseReleaseEvent () from /usr/qt/3/lib/libqt-mt.so.3 #33 0xb6d2cc4f in QScrollView::eventFilter () from /usr/qt/3/lib/libqt-mt.so.3 #34 0xb6cf9f48 in QListView::eventFilter () from /usr/qt/3/lib/libqt-mt.so.3 #35 0xb6c0b19f in QObject::activate_filters () from /usr/qt/3/lib/libqt-mt.so.3 #36 0xb6c0b274 in QObject::event () from /usr/qt/3/lib/libqt-mt.so.3 #37 0xb6c4771f in QWidget::event () from /usr/qt/3/lib/libqt-mt.so.3 #38 0xb6ba9daf in QApplication::internalNotify () from /usr/qt/3/lib/libqt-mt.so.3 #39 0xb6baa076 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3 #40 0xb72a8ad7 in KApplication::notify (this=0xbffff310, receiver=0x823bc70, event=0xbfffed80) at kapplication.cpp:549 #41 0xb6b4386b in QETWidget::translateMouseEvent () from /usr/qt/3/lib/libqt-mt.so.3 #42 0xb6b41ea8 in QApplication::x11ProcessEvent () from /usr/qt/3/lib/libqt-mt.so.3 #43 0xb6b55b35 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3 #44 0xb6bc0701 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3 #45 0xb6bc0656 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3 #46 0xb6ba8f0f in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3 #47 0x08076d70 in main (argc=1347179589, argv=0x504c5445) at main.cpp:99 (gdb)
Steps to duplicate this crash: 1 - launch kopete 2 - open a chat session with one of your contacts. 3 - close the window 4 - open a chat session with another (or the same) contact. THIS WORKS. However, I have noticed that when you Close the window, it doesn't really Close - your previous chats are still there, and if you chat with a new contact, it actually opens a new tab - but leaves your other chat session active. 5 - close the TABS (ctrl-w) until the window closes 6 - open a chat session with another (or the same) contact. CRASH!!!! BANG!!! BURN!!! DIE!!! :) That's what I did to get the above stack trace. It appears that when you close the window, it keeps your session information still there - but when you close the tabs, it complete erases it - but that when you open the chat again, it tries to restore what isn't there... This happens when opening a chat in any way - either from the balloon, or from the contact list. It also happens when you click "ignore" on the balloon (if you had previously closed all tabs instead of closing the window...) One solution is not to close tabs to close the chat windows....problem is, that I'm a creature of habit, and that's just the way that I close my chat windows... ;)
I have this problem too. Please release the fix as a patch to the current release, since we don't want to wait to another kde release to get this fixed. Regards, Paulo Fidalgo
the crash described in comments #8 #9 and #10 is not the same as the original one. this one has already been fixed in cvs for long times, the fix will be in KDE 3.4.1
is there a bug reference or a patch describing the fix for comments 8, 9, and 10?
considering all the stuff in this bug report, i can't really tell where the actual bug is. Is the original bug (crashing when sending multiple lines of text) still an issue?
I've been trying to reproduce this for the last several days with no luck