After hours of running a recent (2-3 days old) SVN, it crashes:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47636523149600 (LWP 32199)]
0x00002b533da77bd3 in std::_Rb_tree_increment () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/libstdc++.so.6
(gdb) bt
#0 0x00002b533da77bd3 in std::_Rb_tree_increment () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/libstdc++.so.6
#1 0x00002b53399ce492 in std::_Rb_tree_const_iterator<bt::AuthenticateBase*>::operator++ (this=0x7fff7164ad60) at stl_tree.h:265
#2 0x00002b53399cd74e in bt::AuthenticationMonitor::update (this=0x5bf5d0) at authenticationmonitor.cpp:106
#3 0x0000000000442d7f in KTorrentCore::update (this=0x9962e0) at ktorrentcore.cpp:557
#4 0x0000000000445397 in KTorrentCore::qt_invoke (this=0x9962e0, _id=5, _o=0x7fff7164af50) at ktorrentcore.moc:243
#5 0x00002b533b7b0a0c in QObject::activate_signal () from /usr/qt/3/lib64/libqt-mt.so.3
#6 0x00002b533b7b16b3 in QObject::activate_signal () from /usr/qt/3/lib64/libqt-mt.so.3
#7 0x00002b533b7cfc95 in QTimer::event () from /usr/qt/3/lib64/libqt-mt.so.3
#8 0x00002b533b75a875 in QApplication::internalNotify () from /usr/qt/3/lib64/libqt-mt.so.3
#9 0x00002b533b75b477 in QApplication::notify () from /usr/qt/3/lib64/libqt-mt.so.3
#10 0x00002b533aad8cbe in KApplication::notify () from /usr/kde/3.5/lib64/libkdecore.so.4
#11 0x00002b533b750fb2 in QEventLoop::activateTimers () from /usr/qt/3/lib64/libqt-mt.so.3
#12 0x00002b533b711f22 in QEventLoop::processEvents () from /usr/qt/3/lib64/libqt-mt.so.3
#13 0x00002b533b76f052 in QEventLoop::enterLoop () from /usr/qt/3/lib64/libqt-mt.so.3
#14 0x00002b533b76ef02 in QEventLoop::exec () from /usr/qt/3/lib64/libqt-mt.so.3
#15 0x00000000004261be in main (argc=3, argv=0x7fff7164b7d8) at main.cpp:122

My gdb session is still open, so please tell me quickly whether you need any more info from gdb, or i'll shut the crashed thing down completely and start seeding again.

I compiled it under gentoo linux with C(XX)FLAGS="-march=athlon64 -pipe -g -ggdb3 -O0", but the same thing also happens with just "-march=athlon64 -pipe -O2".

This appears to be reproducible, as it's random but it has happened at least three times after compiling from the SVN.

Strange, that code hasn't changed in months. And it just crashes when iterating over a std::set, which is also strange.

Is it possible, that another thread actually crashes, but I somehow get a wrong backtrace every time?

EDIT: Ok, using "info threads" etc in gdb I figured out that this would be highly unlikely.

Some more info gathered from gdb:

Code: Select all

(gdb) f 2
#2  0x00002b98102bc17a in bt::AuthenticationMonitor::update (this=0x5bf770) at authenticationmonitor.cpp:106
106                                     itr++;
(gdb) print *this
$3 = {_vptr.AuthenticationMonitor = 0x2b98104430f0, auths = {_M_t = {
      _M_impl = {<std::allocator<std::_Rb_tree_node<bt::AuthenticateBase*> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<bt::AuthenticateBase*> >> = {<No data fields>}, <No data fields>}, _M_key_compare = {<> = {<No data fields>}, <No data fields>}, _M_header = {
          _M_color = std::_S_red, _M_parent = 0x2aaaac7d87f0, _M_left = 0x2aaaacd6c9e0, _M_right = 0x2aaaaccf3270}, _M_node_count = 27}}},
  static self = {_vptr.AuthenticationMonitor = 0x2b98104430f0, auths = {_M_t = {
        _M_impl = {<std::allocator<std::_Rb_tree_node<bt::AuthenticateBase*> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<bt::AuthenticateBase*> >> = {<No data fields>}, <No data fields>}, _M_key_compare = {<> = {<No data fields>}, <No data fields>}, _M_header = {
            _M_color = std::_S_red, _M_parent = 0x2aaaac7d87f0, _M_left = 0x2aaaacd6c9e0, _M_right = 0x2aaaaccf3270}, _M_node_count = 27}}},
    static self = <same as static member of an already seen type>}}
(gdb) print rfds
$4 = {fds_bits = {0 <repeats 16 times>}}
(gdb) print wfds
$5 = {fds_bits = {0 <repeats 16 times>}}
(gdb) print max_fd
$6 = 1408
(gdb) print itr
$7 = {_M_node = 0x2aaaaccf5fe1}
(gdb) print auths.begin()
[Thread 1124096336 (LWP 17799) exited]
$8 = {_M_node = 0x2aaaacd6c9e0}
(gdb) print auths.end()
$9 = {_M_node = 0x5bf780}
(gdb) print ab
$10 = (class bt::AuthenticateBase *) 0x2aaaac7c2d40
(gdb) print ab->getSocket()
$11 = (const class mse::StreamSocket *) 0x2aaaacc6d9c0
(gdb) print ab->getSocket()->fd()
$12 = 1408
(gdb) print ab->getSocket()->connecting()
$13 = false
(gdb) print ab
$14 = (class bt::AuthenticateBase *) 0x2aaaac7c2d40
(gdb) print *ab
$15 = {<> = {<No data fields>}, static metaObj = 0x9d86f0, sock = 0x2aaaacc6d9c0, timer = <incomplete type>, finished = false,
  handshake = '\0' <repeats 67 times>, bytes_of_handshake_recieved = 0, ext_support = 0, local = false}

I think this code is not thread-safe. What if the auths std::set is changed by another thread while this thread is iterating over auths.

According to http://www.sgi.com/tech/stl/set.html:

Set has the important property that inserting a new element into a set does not invalidate iterators that point to existing elements. Erasing an element from a set also does not invalidate any iterators, except, of course, for iterators that actually point to the element that is being erased.

I think this might even be related to http://ktorrent.org/forum/viewtopic.php?t=774. Perhaps update is called several times in parallel or something?

J wrote:Some more info gathered from gdb:

I think this code is not thread-safe.

It doesn't need to be.

What if the auths std::set is changed by another thread while this thread is iterating over auths.

Can't happen, it is only accessed in the main thread.

I think this might even be related to http://ktorrent.org/forum/viewtopic.php?t=774. Perhaps update is called several times in parallel or something?

[/quote]

update is only called from the main thread, it can't be called in parallel.

This segmentation fault is really getting intolerable. I'm now going to compile this with hardened GCC 3.4.6 (PIE+SSP) instead and run it under hardened conditions (PaX etc). I wonder whether this will do any good, but it's still worth a shot, as I'm pretty tired of ktorrent crashing every 40 minutes.

PS: Everyone is welcome to post a shell script here to start and restart ktorrent when it crashes.

You're lucky, Mine crashes around every 5 minutes at least when I have a ton of active torrents.

I've posted a patch in my thread that may help lessen the crashes. Though the stack corruption is still there for me, so I'll be trying to find it tonight.

As for the script:

Code: Select all

#!/bin/bash

KTPID=`pidof ktorrent`
export DISPLAY=:0

if [ "x${KTPID}" == "x" ] ; then
        echo starting ktorrent: `date` 2>&1 >> /home/foo/sbin/ktcheck.log
        nice -n 5 ktorrent --nofork --debug --nocrashhandler 2>&1 > /home/foo/sbin/ktcheck-$$.log
else
        echo ktorrent allready running 2>&1 >> /home/foo/sbin/ktcheck.log
fi

and the cron line:

Code: Select all

*/5 * * * * /home/foo/sbin/ktorrent-check.sh

The pid check may be useless as ktorrent is normally a one instance only type app, but if kt is frozen, this script will freeze too likely.

Thanks Tomasu! As it seems i'm not the only one having these strange crashes.

Because it's likely a duplicate I suggest to close this thread and continue in Tomasu's thread.