Server crash when having a duplicate incomplete file

[rufuscoder]

Original author: baluste...@gmail.com (October 04, 2008 08:40:01)

What steps will reproduce the problem?

1. Start a download of a file with the name "file.avi" (for the sake of purpose)
2. Remove the file from Downloads queue (after it preferably downloaded some bytes)
3. Re search for file "file.avi" and make sure you download again but a different size file that has the same name with the first one.

What is the expected output? What do you see instead? The server will crash

What version of the product are you using? On what operating system? Mac OS X 10.5.5 (Leopard with combo 15.5.5) Intel

macosx:~ packardb$ uname -a Darwin macosx.lan 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep 3 11:29:43 PDT 2008; root:xnu- 1228.7.58~1/RELEASE_I386 i386

Please provide any additional information below.

Process: sphubd [2843] Path: /Applications/ShakesPeer.app/Contents/Resources/sphubd Identifier: sphubd Version: ??? (???) Code Type: X86 (Native) Parent Process: launchd [1]

Date/Time: 2008-10-04 11:31:33.475 +0300 OS Version: Mac OS X 10.5.5 (9F33) Report Version: 6

Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000008 Crashed Thread: 0

Thread 0 Crashed: 0 sphubd 0x00010618 queue_add_internal + 184 1 sphubd 0x0001083f queue_add + 111 2 sphubd 0x00017960 ui_cb_download_file + 128 3 sphubd 0x0001952c ui_cmd_download_file + 156 4 sphubd 0x0002fb9f cmd_dispatch + 335 5 sphubd 0x00019ff7 ui_dispatch_command + 55 6 sphubd 0x00017041 ui_in_event + 97 7 sphubd 0x0005ab09 bufferevent_readcb + 425 8 sphubd 0x00058b6a event_process_active + 282 9 sphubd 0x00058e33 event_base_loop + 407 10 sphubd 0x00058c96 event_loop + 36 11 sphubd 0x00058bac event_dispatch + 18 12 sphubd 0x000155d6 main + 1878 13 sphubd 0x00002062 _start + 216 14 sphubd 0x00001f89 start + 41

Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0x00010571 ecx: 0x00000000 edx: 0x00574dc0 edi: 0x00000000 esi: 0x000163ed ebp: 0xbffff648 esp: 0xbffff610 ss: 0x0000001f efl: 0x00010286 eip: 0x00010618 cs: 0x00000017 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x00000008

Binary Images: 0x1000 - 0x95fe7 +sphubd ??? (???) <f15d8499c734a96808e22d46c8f6bcfc> /Applications/ShakesPeer.app/Contents/Resources/sphubd 0x8fe00000 - 0x8fe2da53 dyld 96.2 (???) <c254337fa28c7eacb3d3e1d56aa141a4> /usr/lib/dyld 0x9001a000 - 0x9010eff4 libiconv.2.dylib ??? (???) <c508c60fafca17824c0017b2e4369802> /usr/lib/libiconv.2.dylib 0x9067f000 - 0x90686fe9 libgcc_s.1.dylib ??? (???) <a9ab135a5f81f6e345527df87f51bfc9> /usr/lib/libgcc_s.1.dylib 0x91654000 - 0x917b4ff3 libSystem.B.dylib ??? (???) <3699b292cde73c2847f87c7e1510d87b> /usr/lib/libSystem.B.dylib 0x9481b000 - 0x9481ffff libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0x94ba4000 - 0x94bb0fff libbz2.1.0.dylib ??? (???) <c5a3563ebe66db7fa456e0fb75b657df> /usr/lib/libbz2.1.0.dylib 0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib

Original issue: http://code.google.com/p/shakespeer/issues/detail?id=75

[rufuscoder]

From hwa...@gmail.com on December 13, 2008 12:20:36 Kevan, any idea about this one? Maybe the bug is in the code you've looked at recently...

[rufuscoder]

From kevan.ca...@gmail.com on December 15, 2008 06:15:44 I'm not having any luck reproducing this.

To test, I created two files using $ dd if=/dev/urandom of=: one is 150 MB in size, one 220 MB. Next, I configure a client on another machine (debian Linux, LinuxDC++ if that matters) to share one of these files, using the filename "file". I then connect both the other machine and the one running ShakesPeer to the same hub. I start the ShakesPeer client downloading whatever file the other machine is sharing, and remove the transfer after it reaches some reasonable level (5 MB or so). I swap files on the other machine, rehash and reconnect as necessary, and then attempt to download the new file.

I tried this on both trunk and r476 (before the code that I looked at recently got changed), and didn't experience any crashes. ShakesPeer attempted to resume the transfer from the file that was left in the incomplete folder from the first transfer, which is probably bad (if these were actual files and not pseudorandom gibberish, the resulting file would probably be broken), but not crash-worthy.

Perhaps I'm missing something?