Bug 145614

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.