Transfer Window causes crashes

[amroth]

KMess crashes a lot when using file transfers, when it brings up or use the Transfer Window. It doesn't happen everytime you use it. Instead, it happens only when you first transfer something, and then don't use it for a good while (read: hours). If, after some time, you transfer more files, then KMess will probably crash.

This is the most hideous bug ever.

[amroth]

I'm not actually sure about some of the attached files; they don't appear to be directly related but KMess crashed EVERYTIME i used file transfers more than once per execution... the bad part is, when I went on investigating, i transferred like twenty files without a problem. But if you're using kmess normally it's far easier to see it crash if someone sends me a file.

Certain conditions: 1) Happens when receiving, i don't think i did see it crash while sending stuff. 2) The first transfer always goes through. Then it appears to crash at a random later file transfer.

[amroth]

This crash too happened in the exact moment it was opening the transferwindow to receive a file, the 5th or 6th for that kmess session.

[amroth]

Probably fixed with commit 1937 or one of the commits of July 8,2007: they fixed a lot of transfer-related problems, and neither I neither Wesbluemarine had a single crash about transfers after it.

[diederik]

Committed another fix in r2053.

The file preview is stored now as instance field first before it's assigned to a widget.

[amroth]

The bug isn't yet solved even after Diederik's huge P2P-related commit. I've yet seen 2 crashes caused by the dreaded transfer window.

I'll upload them.

[amroth]

Stack traces of the last two transfer-window-related crashes. They're painfully similar as the old ones.

[diederik]

I expect this is fixed indirectly by r2078.

I've created ticket #145 to test if there is a chance KMess is exploitable through the direct connection, that caused memory corruption and these weird crashes.

[amroth]

Sorry to reopen, but this crash still occurs at r2083. The attached file "transferwindow.crashes-r2083.trace.tar.gz" contains two stack traces generated with r2082 and r2083.

[diederik]

Most attachments are duplicates. So far I see the following variants in the attachments:

A crash in QDialog::show(), internalNotify():

[KCrash handler]
#5  0xb6a1f814 in QApplication::internalNotify ()
   from /usr/lib/qt-3.3.8/lib/libqt-mt.so.3
#6  0xb6a20599 in QApplication::notify ()
   from /usr/lib/qt-3.3.8/lib/libqt-mt.so.3
#7  0xb71c08ee in KApplication::notify () from /usr/lib/libkdecore.so.4
#8  0xb6c014ce in QDialog::show () from /usr/lib/qt-3.3.8/lib/libqt-mt.so.3
#9  0x0812e6ad in FileTransferP2P::initializeProgressDialog (this=0xaa56110,
    incoming=true, filesize=167029)
    at /www/development/kmess/kmess/network/applications/filetransferp2p.cpp:619
#10 0x0812fa07 in FileTransferP2P::contactStarted2_UserAccepts (
    this=0xaa56110)

These are found in :

• transferwindow2-r2083.trace
• Archiva.tar.bz2
• logs.tar.bz2
• grrrrr damn you transfer window.trace

A crash in QDialog::show, vtable:

[KCrash handler]
#5  0x081734e8 in vtable for ContactAction ()
#6  0xb6a77949 in qt_inheritedBy () from /usr/lib/qt-3.3.8/lib/libqt-mt.so.3
#7  0xb6b0b136 in qt_cast<QPushButton*> ()
   from /usr/lib/qt-3.3.8/lib/libqt-mt.so.3
#8  0xb6bfb450 in QDialog::show () from /usr/lib/qt-3.3.8/lib/libqt-mt.so.3
#9  0x08128519 in FileTransferP2P::initializeProgressDialog (this=0xacd0670,
    incoming=true, filesize=116262)
    at /www/development/kmess/kmess/network/applications/filetransferp2p.cpp:619
#10 0x08129873 in FileTransferP2P::contactStarted2_UserAccepts (
    this=0xacd0670)

Found in:

• transferwindow1-r2083.trace

[amroth]

I've redesigned the way the Transfer Window interacts with the file transfer classes.

Before, FT classes called the Transfer Window, made a new Transfer Entry for it, saving a reference as local property, and then used that reference directly.
This could have lead to crashes in the cases:

1. the Transfer Window gets deleted. All Transfer Entry instances being its children get deleted too, so using any reference to them potentially leads to a crash.
2. The Transfer Entry is deleted from outside the FT class (like with the Clean Up button), so any transfer class which keeps a pointer to it may cause a crash.
3. The Transfer Entry is deleted by the FT class. The Transfer Window still has a reference to it in its internal list, and when you show the window the next time, it tries to update its contents and uses the now broken pointer.

The new situation is much more secure: You just need to call the Transfer Window and make a new entry; you're then given an int 'ticket' which you must use for all subsequent actions of your transfer. Not existing a given ticket, the Transfer Window just ignores the call.

I'm calling it: fixed! woo!

[diederik]

Whoo too!

Note to add, fixes are in r2119. :-)

[amroth]

Sorry to delete the good news, but the bug is still alive and kicking. Our butts.

This time I've got a complete debug output for two subsequent crashes. Posting them.

[amroth]

Committed r2127 to better isolate the Transfer* code.

[diederik]

Committed r2160 to fix pointers with socket fail slots, and the following weird situation:

• connection is established
• contact closes connection before sending stuff.
• timer still fires - shouldn't be - and slotConnectionFailed() is called.
• ApplicationList code didn't reset directConnection_, assuming this code path never happens.
• Some other code writes to directConnection_ starting the memory corruption.

[diederik]

Is this bug still occuring?

[amroth]

I've seen it recently, 15+ days ago. But the P2P bugs weren't preventing me to actually transfer many files.. I'll test this bug in the next days again.

[amroth]

Hopefully fixed with r2211.