Version: 1.0.1 (using KDE KDE 3.5.6) Installed from: Gentoo Packages Compiler: gcc 4.1.2 Compiled using Kernel 2.6.22-rc1, CXXFLAGS="-march=nocona -O2 -pipe -fomit-frame-pointer" OS: Linux Konversation crashes at automatically restoring when starting KDE and receiving quite a whole lot of data via my bouncer. When not getting these huge amounts of data it works as expected. I am using Kernel 2.6.22-rc1 and a freshly recompiled konversation. When starting konversation after the crash by hand and no big backlog is being sent it works as expected, no problems at all. As Bouncer I am using miau (miau.sf.net) with active quicklog. The amount of data is the stuff that comes together in the chans #wesnoth, #wesnoth-de and #wesnoth-dev in about 8 hours (over night). I seem to get this error everytime at boot when at least some time hours were between shutting down and resuming. Backtrace: (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (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) (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) [Thread debugging using libthread_db enabled] [New Thread -1232013648 (LWP 4978)] 0xb7fd9410 in __kernel_vsyscall () #0 0xb7fd9410 in __kernel_vsyscall () #1 0xb699b536 in nanosleep () from /lib/libc.so.6 #2 0xb699b357 in sleep () from /lib/libc.so.6 #3 0xb773e85d in KCrash::startDrKonqi () from /usr/kde/3.5/lib/libkdecore.so.4 #4 0xbfd6bd7c in ?? () #5 0x08298438 in ?? () #6 0x000000a3 in ?? () #7 0xbfd6bd30 in ?? () #8 0xbfd6dd3a in ?? () #9 0xbfd6bd30 in ?? () #10 0x00000003 in ?? () #11 0x0000003f in ?? () #12 0x000013e2 in ?? () #13 0x6f6b7264 in ?? () #14 0x0069716e in ?? () #15 0x7369642d in ?? () #16 0x79616c70 in ?? () #17 0x2e303a00 in ?? () #18 0x2d2d0030 in ?? () #19 0x6e707061 in ?? () #20 0x00656d61 in ?? () #21 0x766e6f6b in ?? () #22 0x61737265 in ?? () #23 0x6e6f6974 in ?? () #24 0x732d2d00 in ?? () #25 0x616e6769 in ?? () #26 0x3131006c in ?? () #27 0x702d2d00 in ?? () #28 0x34006469 in ?? () #29 0x00383739 in ?? () #30 0x70612d2d in ?? () #31 0x72657670 in ?? () #32 0x6e6f6973 in ?? () #33 0x302e3100 in ?? () #34 0x2d00312e in ?? () #35 0x6f72702d in ?? () #36 0x6d617267 in ?? () #37 0x656d616e in ?? () #38 0x6e6f4b00 in ?? () #39 0x73726576 in ?? () #40 0x6f697461 in ?? () #41 0x2d2d006e in ?? () #42 0x61677562 in ?? () #43 0x65726464 in ?? () #44 0x73007373 in ?? () #45 0x696d6275 in ?? () #46 0x75624074 in ?? () #47 0x6b2e7367 in ?? () #48 0x6f2e6564 in ?? () #49 0x2d006772 in ?? () #50 0x6174732d in ?? () #51 0x70757472 in ?? () #52 0x30006469 in ?? () #53 0x00000000 in ?? ()
Unfortunately the above backtrace can not aid in diagnosing the problem. This document will explain how to make useful backtraces (with debugging symbols) on Gentoo Linux: http://www.gentoo.org/proj/en/qa/backtraces.xml
Okay, I will not recompile with debug set for konversation and -g in my CXXFLAGS. I hope this will be enough to produce a reasonable backtrace. I already did another check with simply rebooting my system to make sure it is a problem with the amount of data being sent and not with the new kernel. Since there was about zero data to be transmitted there was no problem directly on boot. I will now check if it is possible to crash konversation when just connecting to the bouncer and getting the backlog after konversation was already running for some time. It will take some time to get enough data in the quicklog... In short: it is not a kernel 2.6.22-rc1 related problem but probably related to the data send via miau that simply is too much to handle for konversation (the miau nouncer is attached directly in a 100MBit network and i got a lag of 5ms).
Many people (including me) regularly use bouncers with backlog replay in concert with Konversation and have reported no problem, so I wouldn't jump to the conclusion that it's a matter of data rate. Many of these bouncers, especially relatively obscure and young projects like miau, have somewhat unorthodox and/or broken implementations of the IRC protocol, however, and it's certainly possible that it sends something we can't handle and crash on. The bt will hopefully tell.
And btw: Remember to remove -fomit-frame-pointer from your CXXFLAGS or you won't get far.
Okay, today it did not crash, the only change I did make was changing the compilerflags from "-march=nocona -O2 -pipe -fomit-frame-pointer" to "-march=nocona -O2 -pipe -g" and not stripping the binary. But instead I am now having another smaller problem, might be related: When connecting to the bouncer it replays the quicklog as it should *until* it gets to the normal dsl disconnection in the miggle of the night. That is the last thing I get in the konversation log. Then the "servertab" for my bouncer still is open, the chans are closed. I have to close the connection to the bouncer and open it again to get the tabs. Maybe something strange happens either with the way miau sends the data for the disconnect, or with how it is handled by konversation. Here is what is in the konversation log: *** Protokolldatei gestartet *** Datum: Sa Mai 19 09:52:04 2007 [Sa Mai 19 2007] [09:52:04] Betreten Sie haben den Kanal #wesnoth-dev betreten (miau@miau). [Sa Mai 19 2007] [09:52:04] Topic Das Kanal-Topic lautet: "151 bugs, 233 feature requests, 1 patches | logs: http: //irclog.wesnoth.org/ | http://wesnoth.org/wiki/Wesconf". [Sa Mai 19 2007] [09:52:04] Notice -Ivanovic an #wesnoth-dev- Playing quicklog... [Sa Mai 19 2007] [09:52:04] Betreten MrJimm hat den Kanal betreten (n=jim@c-24-14-111-0.hsd1.il.comcast.net). [Sa Mai 19 2007] [09:52:04] <CIA-7> [00:41:45] ^C03mog^O * r^B17739^O ^C10^O/trunk/src/serialization/preprocessor.cp p^B:^O [Sa Mai 19 2007] [09:52:04] <CIA-7> [00:41:45] Cache the buffer size and thereby avoid constantly creating and delet ing strings. [Sa Mai 19 2007] [09:52:04] <CIA-7> [00:41:45] This greatly speeds up the preprocessor. [Sa Mai 19 2007] [09:52:04] Betreten alink hat den Kanal betreten (n=alink@host-212-68-216-215.brutele.be). [Sa Mai 19 2007] [09:52:04] Verlassen alink hat den Kanal verlassen. [Sa Mai 19 2007] [09:52:04] Betreten alink hat den Kanal betreten (n=alink@host-212-68-216-215.brutele.be). [Sa Mai 19 2007] [09:52:04] <CIA-7> [02:14:48] ^C03alink^O * r^B17740^O ^C10^O/trunk/data/themes/ (dfool.cfg experim ental.cfg)^B:^O Adapt the 2 remaining themes to the new icon sizes (the general 16px height and the 24px width of flag icon) [Sa Mai 19 2007] [09:52:04] <CIA-7> [02:32:01] ^C03alink^O * r^B17741^O ^C10^O/trunk/data/themes/macros.cfg^B:^O In all themes, adapt the time icon to its new 16x16 size [Sa Mai 19 2007] [09:52:04] Verlassen alink hat den Kanal verlassen. [Sa Mai 19 2007] [09:52:04] <eleazar> [03:03:31] the forum seems to be down again [Sa Mai 19 2007] [09:52:04] Betreten grzywacz hat den Kanal betreten (n=grzywacz@195.69.83.194). [Sa Mai 19 2007] [09:52:04] <happygrue> [03:12:06] yes, forum is also down for me. [Sa Mai 19 2007] [09:52:04] Betreten StarG__ hat den Kanal betreten (n=noone@dslb-088-073-214-190.pools.arcor-ip.net). [Sa Mai 19 2007] [09:52:04] <grzywacz> [03:37:38] same here [Sa Mai 19 2007] [09:52:04] <CIA-7> [03:51:01] ^C03esr^O * r^B17742^O ^C10^O/trunk/src/ (filesystem.cpp game.cpp)^B:^O Solve the multiple-inclusion problem. [Sa Mai 19 2007] [09:52:04] Betreten alink hat den Kanal betreten (n=alink@host-212-68-216-215.brutele.be). [Sa Mai 19 2007] [09:52:04] <esr> [04:17:02] Yay! Map editor's working again! [Sa Mai 19 2007] [09:52:04] <CIA-7> [04:17:32] ^C03esr^O * r^B17743^O ^C10^O/trunk/src/editor/editor_main.cpp^B:^O [Sa Mai 19 2007] [09:52:04] <CIA-7> [04:17:32] The map editor is working again. Problem turned out to be a missing [Sa Mai 19 2007] [09:52:04] <CIA-7> [04:17:32] initialization call that had the effect of making the editor ignore [Sa Mai 19 2007] [09:52:04] <CIA-7> [04:17:32] [binary_path] declarations in .cfg files. [Sa Mai 19 2007] [09:52:04] <esr> [04:17:49] And, just I suspected, problem was that whoever coded it left out an initialization call to the paths manager. [Sa Mai 19 2007] [09:52:04] <esr> [04:18:37] Now all we're waiting on is for YogiHH to get the Windows dirent(3) code working. [Sa Mai 19 2007] [09:52:04] <alink> [04:21:49] esr: good work [Sa Mai 19 2007] [09:52:04] <alink> [04:29:32] note that before there was no binary path in game.cfg (since all data were at root), so not initialize this path was not really an error [Sa Mai 19 2007] [09:52:04] <alink> [04:35:06] esr: I still have 3 times the terrain groups, is it supposed solved too ? or maybe I have some local problem [Sa Mai 19 2007] [09:52:04] <alink> [04:38:15] if not I propose again the same easy solution : remove {core/editor-groups.cfg} from data/core/_main.cfg [Sa Mai 19 2007] [09:52:04] <alink> [04:38:23] it fix the bug [Sa Mai 19 2007] [09:52:04] <alink> [04:40:34] but i suppose that it's indicate that we continue to have some multiple inclusion of the same files [Sa Mai 19 2007] [09:52:05] Betreten Ivanovic_ hat den Kanal betreten (n=ivanovic@pD9EC0D13.dip0.t-ipconnect.de). [Sa Mai 19 2007] [09:52:05] Topic Das Kanal-Topic lautet: "151 bugs, 233 feature requests, 1 patches | logs: http://irclog.wesnoth.org/ | http://wesnoth.org/wiki/Wesconf". [Sa Mai 19 2007] [09:52:05] Topic Das Topic wurde am 17.05.2007 17:46:14 von ivanovic gesetzt. [Sa Mai 19 2007] [09:52:05] Beenden Sie haben diesen Server verlassen ([05:07:57] Read error: 110 (Connection timed out)). And the "complete" log from miau reads like this: May 19 00:41:01 --- client disconnected May 19 00:41:18 --> MrJimm (n=jim@c-24-14-111-0.hsd1.il.comcast.net) has joined #wesnoth-dev May 19 00:41:45 <CIA-7> 03mog * r17739 10/trunk/src/serialization/preprocessor.cpp: May 19 00:41:45 <CIA-7> Cache the buffer size and thereby avoid constantly creating and deleting strings. May 19 00:41:45 <CIA-7> This greatly speeds up the preprocessor. May 19 00:42:40 <-- noy has quit (Read error: 110 (Connection timed out)) May 19 00:42:42 <-- alink has left #wesnoth-dev () May 19 00:42:45 --> alink (n=alink@host-212-68-216-215.brutele.be) has joined #wesnoth-dev May 19 00:42:47 <-- alink has left #wesnoth-dev () May 19 00:43:02 --> alink (n=alink@host-212-68-216-215.brutele.be) has joined #wesnoth-dev May 19 00:45:14 <-- _marx_ has quit (Read error: 110 (Connection timed out)) May 19 01:09:26 <-- daishi has quit (Remote closed the connection) May 19 01:11:10 <-- Mythological has quit ("bye" (null)) May 19 01:16:53 <-- boucman has quit (Remote closed the connection) May 19 01:22:00 <-- Cackfiend has quit ( (null)) May 19 01:24:31 <-- Elvish_Pillager has quit ("Escaping Before It Is Too Late") May 19 01:26:57 --- toma_ is now known as toma May 19 01:28:09 <-- MagicMagor has quit ("This computer has gone to sleep") May 19 01:29:57 <-- MacAnkka has quit ( (null)) May 19 01:31:02 <-- PingPangQui has left #wesnoth-dev () May 19 01:36:01 <-- munxx has quit ("Leaving" (null)) May 19 01:41:08 <-- snax has quit (Remote closed the connection) May 19 02:11:57 <-- mjs-de has quit ( (null)) May 19 02:14:48 <CIA-7> 03alink * r17740 10/trunk/data/themes/ (dfool.cfg experimental.cfg): Adapt the 2 remaining themes to the new icon sizes (the general 16px height and the 24px width of flag icon) May 19 02:20:18 <-- stuffcorpse has quit (Remote closed the connection) May 19 02:32:01 <CIA-7> 03alink * r17741 10/trunk/data/themes/macros.cfg: In all themes, adapt the time icon to its new 16x16 size May 19 02:32:48 <-- grzywacz has quit (Remote closed the connection) May 19 02:35:25 <-- Jan`ger_ has quit (Read error: 104 (Connection reset by peer)) May 19 02:38:33 <-- alink has left #wesnoth-dev () May 19 02:56:05 <-- sparr has quit (Read error: 110 (Connection timed out)) May 19 03:03:31 <eleazar> the forum seems to be down again May 19 03:09:37 --> grzywacz (n=grzywacz@195.69.83.194) has joined #wesnoth-dev May 19 03:11:56 <-- Uz has quit (Read error: 110 (Connection timed out)) May 19 03:12:06 <happygrue> yes, forum is also down for me. May 19 03:36:59 --> StarG__ (n=noone@dslb-088-073-214-190.pools.arcor-ip.net) has joined #wesnoth-dev May 19 03:37:38 <grzywacz> same here May 19 03:38:02 <-- StarG has quit (Read error: 60 (Operation timed out)) May 19 03:51:01 <CIA-7> 03esr * r17742 10/trunk/src/ (filesystem.cpp game.cpp): Solve the multiple-inclusion problem. May 19 03:55:11 --> alink (n=alink@host-212-68-216-215.brutele.be) has joined #wesnoth-dev May 19 04:17:02 <esr> Yay! Map editor's working again! May 19 04:17:32 <CIA-7> 03esr * r17743 10/trunk/src/editor/editor_main.cpp: May 19 04:17:32 <CIA-7> The map editor is working again. Problem turned out to be a missing May 19 04:17:32 <CIA-7> initialization call that had the effect of making the editor ignore May 19 04:17:32 <CIA-7> [binary_path] declarations in .cfg files. May 19 04:17:49 <esr> And, just I suspected, problem was that whoever coded it left out an initialization call to the paths manager. May 19 04:18:37 <esr> Now all we're waiting on is for YogiHH to get the Windows dirent(3) code working. May 19 04:21:49 <alink> esr: good work May 19 04:29:32 <alink> note that before there was no binary path in game.cfg (since all data were at root), so not initialize this path was not really an error May 19 04:35:06 <alink> esr: I still have 3 times the terrain groups, is it supposed solved too ? or maybe I have some local problem May 19 04:38:15 <alink> if not I propose again the same easy solution : remove {core/editor-groups.cfg} from data/core/_main.cfg May 19 04:38:23 <alink> it fix the bug May 19 04:40:34 <alink> but i suppose that it's indicate that we continue to have some multiple inclusion of the same files May 19 04:51:03 <-- Ivanovic has quit (Server dropped connection!) **** BEGIN LOGGING AT Sat May 19 04:51:18 2007 May 19 04:51:18 --> Ivanovic_ (n=ivanovic@pD9EC0D13.dip0.t-ipconnect.de) has joined #wesnoth-dev May 19 05:07:57 <-- Ivanovic has quit (Read error: 110 (Connection timed out)) May 19 05:09:51 --- Ivanovic_ is now known as Ivanovic May 19 05:13:18 <-- Obfuscate has quit (anthony.freenode.net irc.freenode.net) The konversationlog stops at the reconnect of miau to freenode. Might this be where it did have problems that resulted into the crash? Is it a new bug that I should report seperatly? Or is it just a bug on the side of miau and how the data is sent?
Okay, today I had another crash: Eine korrekte Rückverfolgung ist nicht möglich. Wahrscheinlich sind die Dateien Ihres Systems in einer Weise erstellt worden, die eine solche Rückverfolgung (Backtrace) nicht erlaubt. Oder der so genannte "Stack Frame" für das Programm wurde durch den Absturz unbrauchbar gemacht. Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1232722256 (LWP 4835)] 0xb7f2c410 in __kernel_vsyscall () #0 0xb7f2c410 in __kernel_vsyscall () #1 0xb68ee536 in ?? () from /lib/libc.so.6 #2 0xb68ee357 in sleep () from /lib/libc.so.6 #3 0xb769185d in KCrash::startDrKonqi () from /usr/kde/3.5/lib/libkdecore.so.4 #4 0xb68cb9f8 in malloc () from /lib/libc.so.6 Backtrace stopped: previous frame inner to this frame (corrupt stack?) The whole system is now compiled with "-march=nocona -O2 -pipe -g", not stripped and konversation build with the debug useflag.
Unfortunately the backtrace is still useless and doesn't touch upon what if anything happens inside Konversation (compare with e.g. http://www.eikehein.com/backtrace1.txt for an example of a proper backtrace) -- if your build environment is correct, it might be a hardware problem.
I am sure that my buildenvironment is working (I did just rebuild my whole system and it did work without a flaw). It is setup exactly the way described in the link you gave me about debug stuff under gentoo. And I am rather sure that my Hardware itself is okay, too, since I had no other such problems with any other prog before. I will see if I get a more responsive error later this day, at least that is what I hope...
Okay, today it crashed again and now it looks like I got something like a backtrace: Short description of the prob (in german): Das Programm Konversation (konversation) ist abgestürzt und hat das Signal 11 (SIGSEGV) veranlasst. Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1233353040 (LWP 4959)] [KCrash handler] #6 InputFilter::parseClientCommand (this=0x839a6bc, prefix=@0xbfac13fc, command=@0xbfac13f8, parameterList=@0xbfac13f4, _trailing=@0xbfac1404) at inputfilter.cpp:153 #7 0x080dfbed in InputFilter::parseLine (this=0x839a6bc, a_newLine=@0xbfac147c) at inputfilter.cpp:112 #8 0x08105309 in Server::processIncomingData (this=0x839a4f0) at server.cpp:1024 #9 0x08109044 in Server::qt_invoke (this=0x839a4f0, _id=54, _o=0xbfac1628) at server.moc:874 #10 0xb703503e in QObject::activate_signal (this=0x839a584, clist=0x83c6918, o=0xbfac1628) at kernel/qobject.cpp:2356 #11 0xb7035b80 in QObject::activate_signal (this=0x839a584, signal=2) at kernel/qobject.cpp:2325 #12 0xb734a7f1 in QTimer::timeout (this=0x839a584) at .moc/release-shared-mt/moc_qtimer.cpp:82 #13 0xb70560be in QTimer::event (this=0x839a584, e=0xbfac18e4) at kernel/qtimer.cpp:219 #14 0xb6fd9f45 in QApplication::internalNotify (this=0xbfac1b04, receiver=0x839a584, e=0xbfac18e4) at kernel/qapplication.cpp:2635 #15 0xb6fdaaa2 in QApplication::notify (this=0xbfac1b04, receiver=0x839a584, e=0xbfac18e4) at kernel/qapplication.cpp:2358 #16 0xb76fdd34 in KApplication::notify (this=0xbfac1b04, receiver=0x839a584, event=0xbfac18e4) at kapplication.cpp:550 #17 0xb6fcfcba in QEventLoop::activateTimers (this=0x825b688) at kernel/qapplication.h:496 #18 0xb6f8cd24 in QEventLoop::processEvents (this=0x825b688, flags=4) at kernel/qeventloop_x11.cpp:389 #19 0xb6fef8fd in QEventLoop::enterLoop (this=0x825b688) at kernel/qeventloop.cpp:198 #20 0xb6fef7a2 in QEventLoop::exec (this=0x825b688) at kernel/qeventloop.cpp:145 #21 0xb6fd9a6b in QApplication::exec (this=0xbfac1b04) at kernel/qapplication.cpp:2758 #22 0x0810fed9 in main (argc=3, argv=) at main.cpp:109 Like I already stated before: Now that I am using debug symbols and stuff it does not crash this often anymore. But the usual case is that chans are "lost" when attaching the bouncer. This means all the chans are shown for a short times and then some vanish again. To really have them shown I do have to close the connection to that "server" (my bouncer) and reconnect, then I do get all the chans as expected. I assume it is somehow connected to the way disconnects are handled because it only hapens when quite some data and a disconnect of the irc client come together (I am using the bouncer on a normal dsl line with a 24h disconnect).
Okay, had another crash, basically looking identical in the bt: Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1233426768 (LWP 4917)] [KCrash handler] #6 InputFilter::parseClientCommand (this=0x839a704, prefix=@0xbff747ec, command=@0xbff747e8, parameterList=@0xbff747e4, _trailing=@0xbff747f4) at inputfilter.cpp:153 #7 0x080dfbed in InputFilter::parseLine (this=0x839a704, a_newLine=@0xbff7486c) at inputfilter.cpp:112 #8 0x08105309 in Server::processIncomingData (this=0x839a538) at server.cpp:1024 #9 0x08109044 in Server::qt_invoke (this=0x839a538, _id=54, _o=0xbff74a18) at server.moc:874 #10 0xb702303e in QObject::activate_signal (this=0x839a5cc, clist=0x83c65a0, o=0xbff74a18) at kernel/qobject.cpp:2356 #11 0xb7023b80 in QObject::activate_signal (this=0x839a5cc, signal=2) at kernel/qobject.cpp:2325 #12 0xb73387f1 in QTimer::timeout (this=0x839a5cc) at .moc/release-shared-mt/moc_qtimer.cpp:82 #13 0xb70440be in QTimer::event (this=0x839a5cc, e=0xbff74cd4) at kernel/qtimer.cpp:219 #14 0xb6fc7f45 in QApplication::internalNotify (this=0xbff74ef4, receiver=0x839a5cc, e=0xbff74cd4) at kernel/qapplication.cpp:2635 #15 0xb6fc8aa2 in QApplication::notify (this=0xbff74ef4, receiver=0x839a5cc, e=0xbff74cd4) at kernel/qapplication.cpp:2358 #16 0xb76ebd34 in KApplication::notify (this=0xbff74ef4, receiver=0x839a5cc, event=0xbff74cd4) at kapplication.cpp:550 #17 0xb6fbdcba in QEventLoop::activateTimers (this=0x825b688) at kernel/qapplication.h:496 #18 0xb6f7ad24 in QEventLoop::processEvents (this=0x825b688, flags=4) at kernel/qeventloop_x11.cpp:389 #19 0xb6fdd8fd in QEventLoop::enterLoop (this=0x825b688) at kernel/qeventloop.cpp:198 #20 0xb6fdd7a2 in QEventLoop::exec (this=0x825b688) at kernel/qeventloop.cpp:145 #21 0xb6fc7a6b in QApplication::exec (this=0xbff74ef4) at kernel/qapplication.cpp:2758 #22 0x0810fed9 in main (argc=3, argv=) at main.cpp:109
Since I was asked to test if the problems were fixed in svn, I did test it and it does not work there either. Some more detailed version infos about the svn rev I did use to test: URL: svn://anonsvn.kde.org/home/kde/branches/extragear/kde3/network/konversation Revision: 685231 At least the bug about "vanishing chan tabs" does still exist and probably the bug about crashing in about 10% of all cases is not fixed either.
Closing. See #147976 for the continuation of the "vanishing tabs" issue.