Remote crash when user downloads from merged share

[E_zombie]

revno: 337

$ linuxdcpp
Loading: Hash database
Loading: Shared Files
Loading: Download Queue
terminate called after throwing an instance of 'std::length_error'
  what(): basic_string::_S_create
Аварийный останов (core dumped)

core+linuxdcpp

ftp://ftp.san.ru/temp/crash-linuxdcpp/2009111001/

[Steven Sheehy (steven-sheehy)]

Is this reproducible? It seems to crash when someone searches your share. Any idea what they searched for and on what share item it crashed? It would be nice if we could add some print outs to determine those.

std::length_error is thrown when string attempted to be created that is greater than its maximum possible size. It looks like it occurs when generating the search result path, but I don't think it's possible that you are sharing a path that is greater than 4611686018427387897 characters.

Also, your executable is i386 (I'm x86-64) and is not in debug mode so I am not able to see all symbols. It would be preferable if you compiled it in debug mode, reproduced it, and attached the output of "backtrace full" as a text file to this bug.

[Steven Sheehy (steven-sheehy)]

Please try latest ppa that has debugs enabled:

https://launchpad.net/~linuxdcpp-team/+archive/ppa

[E_zombie (lv77)]

crash 100% reproduce after add other "download" directory in share.

....................
Adding new directory mp3
Adding new directory download
Adding new directory мой_рабочай_комп
Adding new directory православие
Adding new directory video
Adding new directory anime
Merging directory download
Adding new directory games-ftp.san.ru
Adding new directory linux
........

[] 11:11:51 /home/lv77/Общедоступные :
# du -sh ./
146M ./

# du -sh /mnt/msa2012i.1/download/
3,6G /mnt/msa2012i.1/download/

[E_zombie (lv77)]

core + bin + filelist

ftp://ftp.san.ru/temp/crash-linuxdcpp/2009111601/

[Steven Sheehy (steven-sheehy)]

Please do not provide core + bin files. I am on a different architecture than you. Please run `gdb --core=core.31986 linuxdcpp` and attach the output of "backtrace full" as a text file to this bug.

[Steven Sheehy (steven-sheehy)]

Also, did your /mnt/*/download show up in your share? I don't see it in your filelist (but maybe it just hadn't refreshed yet). And did it crash while hashing one of the download folders or did it crash when somebody tried to download a file from the download directories?

[Steven Sheehy (steven-sheehy)]

Ok, nevermind about files showing up in share. They should be combined under one download hierarchy in your filelist, not separate like I assumed.

[Steven Sheehy (steven-sheehy)]

I was able to reproduce it. This is a remote crashing bug that is a side-effect of the fix for bug #351393. In that bug, we changed ShareManager::Directory::File to not store an intrusive_ptr since it was leaking memory. This is fine for normal directories since its ptr will be kept around elsewhere, but when a directory is merged into another virtual directory that intrusive_ptr reference gets lost and the object is garbage collected. Later when a user tries to download a file from this merged directory, it tries to get the real path using the previously gc'd object and crashes.

1) Add path /A/ to virtual share C
2) Add path /B/ to virtual share C. B is merged into share C
3) User downloads C/a (real path /A/a) and is successful
4) User downloads C/b (real path /B/b) and remotely crashes client

[Jacek Sieka (arnetheduck)]

Sounds reasonable, I added refcounting there so that I wouldn't have to keep track of virtual shares manually...
Could someone revert the patch for now? (better eat memory than crash...)

[Jacek Sieka (arnetheduck)]

this was never realeased so we don't need the bug...fixed anyway...

[Steven Sheehy (steven-sheehy)]

Just because it wasn't released doesn't mean the bug is marked invalid. Doing so discourages people from running the latest trunk to test and find regressions. Regressions are of course not mentioned in the release notes, but they should still be tracked and marked as fixed in the bug tracker.

Regardless, I've ported Jacek's fix to latest linuxdcpp trunk so marking as fixed.