I have had 3 segfault recently with ktorrent :
(link not valid anymore)

These links don't seem to work... timeout. Anyway, I'm also having segmentation faults. This segmentation fault has occured in previous versions also, but now ktorrent crashes almost immediately.

backtrace:
#0 0x0000000000429c57 in KTorrentCore::update ()
#1 0x000000000042b47b in KTorrentCore::qt_invoke ()
#2 0x00002ba2d4e3654c in QObject::activate_signal () from /usr/qt/3/lib64/libqt-mt.so.3
#3 0x00002ba2d4e371f3 in QObject::activate_signal () from /usr/qt/3/lib64/libqt-mt.so.3
#4 0x00002ba2d4e557d5 in QTimer::event () from /usr/qt/3/lib64/libqt-mt.so.3
#5 0x00002ba2d4de0445 in QApplication::internalNotify () from /usr/qt/3/lib64/libqt-mt.so.3
#6 0x00002ba2d4de1047 in QApplication::notify () from /usr/qt/3/lib64/libqt-mt.so.3
#7 0x00002ba2d406139e in KApplication::notify () from /usr/kde/3.5/lib64/libkdecore.so.4
#8 0x00002ba2d4dd6bb2 in QEventLoop::activateTimers () from /usr/qt/3/lib64/libqt-mt.so.3
#9 0x00002ba2d4d97dd2 in QEventLoop::processEvents () from /usr/qt/3/lib64/libqt-mt.so.3
#10 0x00002ba2d4df4c22 in QEventLoop::enterLoop () from /usr/qt/3/lib64/libqt-mt.so.3
#11 0x00002ba2d4df4ad2 in QEventLoop::exec () from /usr/qt/3/lib64/libqt-mt.so.3
#12 0x000000000041bcdd in main ()
#13 0x00002ba2d762063c in __libc_start_main () from /lib/tls/libc.so.6
#14 0x000000000041ba0a in _start ()

assembly:
0x0000000000429c40 <_ZN12KTorrentCore6updateEv+0>: push %rbp
0x0000000000429c41 <_ZN12KTorrentCore6updateEv+1>: mov %rdi,%rbp
0x0000000000429c44 <_ZN12KTorrentCore6updateEv+4>: push %rbx
0x0000000000429c45 <_ZN12KTorrentCore6updateEv+5>: sub $0x8,%rsp
0x0000000000429c49 <_ZN12KTorrentCore6updateEv+9>: callq 0x418ea0 <_ZN2bt7Globals8instanceEv@plt>
0x0000000000429c4e <_ZN12KTorrentCore6updateEv+14>: mov 0x18(%rax),%rdi
0x0000000000429c52 <_ZN12KTorrentCore6updateEv+18>: callq 0x418100 <_ZN2bt6Server6updateEv@plt>
0x0000000000429c57 <_ZN12KTorrentCore6updateEv+23>: mov 0xd8(%rbp),%rdi
0x0000000000429c5e <_ZN12KTorrentCore6updateEv+30>: callq 0x419b50 <_ZN2bt12QueueManager5beginEv@plt>
0x0000000000429c63 <_ZN12KTorrentCore6updateEv+35>: mov %rax,%rbx
0x0000000000429c66 <_ZN12KTorrentCore6updateEv+38>: jmp 0x429c6c <_ZN12KTorrentCore6updateEv+44>
0x0000000000429c68 <_ZN12KTorrentCore6updateEv+40>: mov 0x10(%rbx),%rbx
0x0000000000429c6c <_ZN12KTorrentCore6updateEv+44>: mov 0xd8(%rbp),%rdi

With the assembler output I can see where it crashes (right after the call to Server::update),

It seems that :

mov 0xd8(%rbp),%rdi

Tries to load some value from an invalid memory address in the rdi register, or the rdi register gets copied to some invalid address. (I have to look it up)

The question is why is the address invalid ?

AT&T syntax is mov source,destination

J wrote:0x0000000000429c41 <_ZN12KTorrentCore6updateEv+1>: mov %rdi,%rbp

move "this" to rdp

J wrote:0x0000000000429c57 <_ZN12KTorrentCore6updateEv+23>: mov 0xd8(%rbp),%rdi

0xd8(%rbp) is probaly this->qman, where this is the instance of KTorrentCore, so this statement likely changes the "this" pointer to point to qman to call begin() on it.

My guess is that either that

• the instance of KTorrentCore is destroyed before reaching these instructions (I don't know whether this would trigger a SIGSEGV thou) or
• this->qman gets destroyed before reaching these instructions

0xd8(%rbp) is probaly this->qman, where this is the instance of KTorrentCore, so this statement likely changes the "this" pointer to point to qman to call begin() on it.

My guess is that either that

• the instance of KTorrentCore is destroyed before reaching these instructions (I don't know whether this would trigger a SIGSEGV thou) or
  

It would trigger a SIGSEGV, every time you access a memory page which you do not own, you get a SIGSEGV.

It is impossible that KTorrentCore is destroyed, because that gets created at the start and is only deleted at exit.

this->qman gets destroyed before reaching these instructions

Which should also be impossible, because the first thing KTorrentCore does is create qman and it only destroys it in it's destructor.

I need some way of reproducing this otherwise we're not gonna get very far.

Say, did you guys use a binary package, or did you compile from source ?

George wrote:Say, did you guys use a binary package, or did you compile from source ?

I use Gentoo, so portage compiled it from source.

Ok, compiled it directly from source with "-g -ggdb3". The "this" pointer is 0x0. So this is what is causing the segmentation fault:

Code: Select all

#0  KTorrentCore::update (this=0x0) at ktorrentcore.cpp:459
#1  0x000000000042bd0b in KTorrentCore::qt_invoke (this=0x0, _id=4, _o=0x7fff23443bd0) at ktorrentcore.moc:229

J wrote:Ok, compiled it directly from source with "-g -ggdb3". The "this" pointer is 0x0. So this is what is causing the segmentation fault:

Code: Select all

#0  KTorrentCore::update (this=0x0) at ktorrentcore.cpp:459
#1  0x000000000042bd0b in KTorrentCore::qt_invoke (this=0x0, _id=4, _o=0x7fff23443bd0) at ktorrentcore.moc:229

That shouldn't happen, the update function is triggered by a QTimer which gets started from the constructor of KTorrentCore.

Can you post the full backtrace ?

George wrote:Can you post the full backtrace ?

As only ktorrent was compiled with -g -ggdb3 the rest of the backtrace is identical to that in my first post (second post on this thread).

J wrote:

George wrote:Can you post the full backtrace ?

As only ktorrent was compiled with -g -ggdb3 the rest of the backtrace is identical to that in my first post (second post on this thread).

I'm interested in the this pointer the call one higher on the stack (KTorrentCore::qt_invoke)

If I look at qt_invoke, it should allready crash there, seeing that members of KTorrentCore are accessed in there, so if the this pointer is 0, it should crash there.

Also, if you go into ~/.kde/share/apps/ktorrent and rename the dirrectories tor0, tor1, anything named tor with a number behind it to something else, and you restart KT, does the crash still happen ?

this is 0x0 in qt_invoke:

J wrote:

Code: Select all

#0  KTorrentCore::update (this=0x0) at ktorrentcore.cpp:459
#1  0x000000000042bd0b in KTorrentCore::qt_invoke (this=0x0, _id=4, _o=0x7fff23443bd0) at ktorrentcore.moc:229

and the "this" pointer is NOT used in qt_invoke. This is the function from my ktorrentcore.moc file:

Code: Select all

bool KTorrentCore::qt_invoke( int _id, QUObject* _o )
{
    switch ( _id - staticMetaObject()->slotOffset() ) {
    case 0: load((const QString&)static_QUType_QString.get(_o+1),(const QString&)static_QUType_QString.get(_o+2),(bool)static_QUType_bool.get(
_o+3)); break;
    case 1: remove((kt::TorrentInterface*)static_QUType_ptr.get(_o+1),(bool)static_QUType_bool.get(_o+2)); break;
    case 2: update(); break;
    case 3: start((kt::TorrentInterface*)static_QUType_ptr.get(_o+1)); break;
    case 4: stop((kt::TorrentInterface*)static_QUType_ptr.get(_o+1)); break;
    case 5: stop((kt::TorrentInterface*)static_QUType_ptr.get(_o+1),(bool)static_QUType_bool.get(_o+2)); break;
    case 6: queue((kt::TorrentInterface*)static_QUType_ptr.get(_o+1)); break;
    case 7: aboutToBeStarted((kt::TorrentInterface*)static_QUType_ptr.get(_o+1),(bool&)static_QUType_bool.get(_o+2)); break;
    case 8: torrentFinished((kt::TorrentInterface*)static_QUType_ptr.get(_o+1)); break;
    case 9: slotStoppedByError((kt::TorrentInterface*)static_QUType_ptr.get(_o+1),(QString)static_QUType_QString.get(_o+2)); break;
    case 10: torrentSeedAutoStopped((kt::TorrentInterface*)static_QUType_ptr.get(_o+1)); break;
    default:
        return QObject::qt_invoke( _id, _o );
    }
    return TRUE;
}

The "this" pointer is passed to qt_invoke in %rdi and the value is also passed to update() in %rdi. In both cases, %rdi is null. Maybe it's a qt issue?

At first sight this appears to be accessing members :

staticMetaObject()->slotOffset()

But apparently it isn't.

Anyway the question is how the hell does KTorrentCore get to be 0x0.

In the constructor of KTorrentCore we do this :

connect(&update_timer,SIGNAL(timeout()),this,SLOT(update()));
update_timer.start(250);

Seeing that this is 0 in the call to update, it must also be 0 here (but then we would get a crash in the constructor). Seeing that I can't reproduce it, can you step through it with a debugger and see what the value of this is at that point ?

The "this" pointer in the constructor wasn't null when i last checked it. It might be a qt bug.

This is certainly weird, maybe we should start the timer outside of the constructor ?

As KTorrent is a multithreaded application, maybe the timer thread calls update() just while KTorrentCore gets destroyed by another thread?