out of memory if share contains broken directory names

Bug #300728 reported by Alexander Sashnov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
DC++
Fix Released
Low
Unassigned
LinuxDC++
Confirmed
High
Unassigned

Bug Description

linuxdcpp-1.0.2
Filesystem: ext3 utf8
Default hub encoding: CP1251 (Cyrillic)

All works fine until I create on share directory with name in broken encoding.
Linuxdcpp eat all memory (RSS size more than 700 mb) and killed by OOM.

Tags: filename
Revision history for this message
Alexander Sashnov (sashnov) wrote :
Revision history for this message
Razzloss (razzloss) wrote :

Well... This looks oddly familiar.

https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2353&group_id=2230

And probably has the same problem still. The question is if it's better to crash the client or share something that wasn't intended? Or even better, fix the problem so that neither occurs.

--RZ

Revision history for this message
qwertitis (qwertitis-deactivatedaccount) wrote :

See also bug #287982

Changed in linuxdcpp:
status: New → Confirmed
Revision history for this message
Alexander Sashnov (sashnov) wrote :

Ok, we can show message box (with directory name contains bad file/folders) end exit.
Or show dialog with Abort, Retry and Ignore buttons ;)
Or just crash with message to stderr (user will see it in .xsession-errors).

Revision history for this message
qwertitis (qwertitis-deactivatedaccount) wrote :

I think those suggestions are lousy ways to deal with these kinds of errors. Optimally the files would be shared w/o trouble, if that's not feasible, just ignore them.

Revision history for this message
Alexander Sashnov (sashnov) wrote :

I think optimal solution it is just dump warning to stderr (~/.xsession-errors) and continue.

Revision history for this message
Razzloss (razzloss) wrote :

If we'll go with the dump error & continue, it should atleast be dumped to LogManager and shown in the main statusbar. That way it's remotely possible that user who doesn't run from the console will ever see it.

--RZ

Changed in linuxdcpp:
importance: Undecided → High
Revision history for this message
eMTee (realprogger) wrote :

Not sure the Win32 implementation of FileFindIter can ever return an empty string but if it does, it does not crash DC++, the result is a simple error message in the log : Error hashing <dirve:\folder\>: cannot the file specified.
However this message is misleading so if the attached patch satisfy you, it would fix both problem in both platforms.

Changed in dcplusplus:
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
eMTee (realprogger) wrote :
Revision history for this message
poy (poy) wrote :

can't hurt to check, please add.

Revision history for this message
Razzloss (razzloss) wrote :

Except that the same check led to a situation where something unintentional was shared. This was with an old version of LinuxDC++ (0.691 I believe) and required some character encoding changes between 2 executions.

I didn't manage to reproduce the effect with 0.75 core though, but don't know if it is because I don't remember the steps correctly or because other changes in the hashmanager code.

But yes, it can hurt to check (of course the other option was a crash in that situation, you decide which is more painful).

--RZ

Revision history for this message
eMTee (realprogger) wrote :

Again, crash can only happen in the *nix part of the code, under Windows this causes a minor problem only. Because of this I think its better that you (I mean linuxdc++ devs, or the one who set this bug affects DC++) decide what to do / fix the unix part / remove DC++ from affected list...

Revision history for this message
Steven Sheehy (steven-sheehy) wrote :

Just to be clear, removing DC++ from the affected list is not a valid option. Since the DC++ project includes both the win32 GUI and the dcpp core, any defect that modifies the core regardless of whether it's *nix or windows specific should be marked as affecting DC++. If you're not okay with this, then you might think about splitting DC++ and libdcpp into separate launchpad projects.

As for the patch, since Razzloss is unable to reproduce his issue with sharing directories unintentionally on the current core, I'm okay with committing the patch as is. If someone later reproduces the issue then that will be addressed as a separate defect.

eMTee (realprogger)
Changed in dcplusplus:
status: Confirmed → Fix Committed
Revision history for this message
poy (poy) wrote :

Fixed in DC++ 0.780.

Changed in dcplusplus:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.