aMule Forum
English => aMule crashes => Topic started by: wires on June 22, 2009, 09:42:50 AM
-
Hi all,
I've got a crash running SVN 9677 on Fedora 11 amd64 immediately after cancelling a download that was also uploading.
----------------------------=| BACKTRACE FOLLOWS: |=----------------------------
Current version is: aMule SVN using wxGTK2 v2.8.10 (Snapshot: rev. 9677)
Running on: Linux 2.6.29.4-167.fc11.x86_64 x86_64
[2] CamuleApp::OnFatalException() in :0
[3] wxFatalSignalHandler in /usr/lib64/libwx_baseu-2.8.so.0[0x3b562f85fc]
[4] ?? in /lib64/libpthread.so.0 [0x3d0260ee90]
[5] CUploadQueue::CheckForTimeOver(CUpDownClient*) in :0
[6] CUpDownClient::SendBlockData() in :0
[7] CUploadQueue::Process() in :0
[8] CamuleApp::OnCoreTimer(CTimerEvent&) in :0
[9] wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) in /usr/lib64/libwx_baseu-2.8.so.0[0x3b562f3f84]
[10] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) in /usr/lib64/libwx_baseu-2.8.so.0[0x3b562f4fc4]
[11] wxEvtHandler::ProcessEvent(wxEvent&) in /usr/lib64/libwx_baseu-2.8.so.0[0x3b562f50b7]
[12] wxEvtHandler::ProcessPendingEvents() in /usr/lib64/libwx_baseu-2.8.so.0[0x3b562f43f8]
[13] wxAppConsole::ProcessPendingEvents() in /usr/lib64/libwx_baseu-2.8.so.0[0x3b56262949]
[14] wxAppBase::ProcessIdle() in /usr/lib64/libwx_gtk2u_core-2.8.so.0[0x32b2270deb]
[15] ?? in /usr/lib64/libwx_gtk2u_core-2.8.so.0 [0x32b21ced93]
[16] g_main_context_dispatch in /lib64/libglib-2.0.so.0[0x32ae237afe]
[17] ?? in /lib64/libglib-2.0.so.0 [0x32ae23b1d8]
[18] g_main_loop_run in /lib64/libglib-2.0.so.0[0x32ae23b635]
[19] gtk_main in /usr/lib64/libgtk-x11-2.0.so.0[0x32b03279c7]
[20] wxEventLoop::Run() in /usr/lib64/libwx_gtk2u_core-2.8.so.0[0x32b21e6448]
[21] wxAppBase::MainLoop() in /usr/lib64/libwx_gtk2u_core-2.8.so.0[0x32b2270c7b]
[22] wxEntry(int&, wchar_t**) in /usr/lib64/libwx_baseu-2.8.so.0[0x3b5629850c]
[23] main in :0
[24] __libc_start_main in /lib64/libc.so.6[0x3d01a1ea2d]
[25] _start in :0
Configure command:
$ ../configure --prefix=/home/xxxxx/aMule-SVN --disable-dependency-tracking --disable-upnp --enable-geoip --enable-optimize --disable-debug --enable-mmap
wx : 2.8.10
gcc: 4.4.0
crypto++: 5.6.0
Edit: add some more info
Also just changed skin to priscilla
I'm building a debug version to check again and get a useful backtrace.
Cheers
-
Thank you for reporting!
This is nasty. It appears that on canceling a download the uploadlist is not processed. Then, some time later in CUpDownClient::CreateNextBlockPackage there's a CKnownFile* srcfile = theApp->sharedfiles->GetFileByID(CMD4Hash(currentblock->FileID));
if (!srcfile) {
throw wxString(wxT("requested file not found"));
}
which disconnects the client.
Before that, there is now a crash in CUploadQueue::CheckForTimeOver in cur_client->GetUploadFile()->GetUpPriority() because the CKnowFile pointed to was deleted.
I could copy the GetFileByID check over here too, but I'd prefer to go to the root of the problem and kick the clients from the uploadqueue on canceling a download.
Opinions?
-
Go ahead.
-
Ok.
Wires, I forgot to say your backtrace was already useful enough, no need for a second one in debug mode.
-
Ok, thank you!
-
Fixed in 9688.
If you'd like to test the fix I suggest you apply this patch first:
Index: PartFile.cpp
===================================================================
--- PartFile.cpp (revision 9688)
+++ PartFile.cpp (working copy)
@@ -2234,6 +2234,7 @@
AddDebugLogLineM(false, logPartFile, wxT("\tClosed"));
+return; // Only for testing !!!
if (!CPath::RemoveFile(m_fullname)) {
AddDebugLogLineM(true, logPartFile, CFormat(wxT("\tFailed to delete '%s'")) % m_fullname);
} else {
So you can "cancel" your uploading downloads and they will be resurrected on next restart of the client. :)
(Or backup your temp dir.)
-
Stu, I know I told you to do it, but: before we used to upload already buffered data - i.e. the already read 180K chunk.
We should consider if we need this to be done and act accordingly.
-
If a user decides to cancel a download he probably doesn't want it to continue uploading anyway. He'd rather have his bandwidth go to his ongoing downloads to gain credits or to his shares. Mind, the reason for canceling is often that it turns out to be fake after preview or filename examination.
-
I usually cancel a download when I realize it is not what i expected or it is a fake.
I've checked the patch and it works. Kicking clients from the upload queue takes a while. May be it is kicking all clients that requested the file instead of just those active (slot assigned)? I think it would be better to clean the active slots, other peers (waiting) should get some kind of "file not available" on next request.
Regards
-
Kicking clients from the upload queue takes a while.
Works in an instant for me, even if I cancel a release prio file all slots are downloading. And it only processes the active slots.
How long does it take? Is the client blocked meanwhile? Log messages?
-
You're right tested again and it worked very quick.
Thanks again
Edit: mark as solved