Crash when 'Keep duplicate files in your file list' is disabled and a small shared file is renamed

Bug #362598 reported by eMTee
24
Affects Status Importance Assigned to Milestone
DC++
Fix Released
High
Unassigned

Bug Description

To reproduce I need to
- Share a file smaller than 1MiB
- Disable 'Keep duplicate files in your file list'
- Rename the file in your share
- Refresh filelist

The problem is that for some reason the newly found (renamed) file is considered as a dupe. The call for the real path of the nonexistent dupe file (needed for the LogManager message) throws an exception which is unhandled in ShareManager::updateIndices(File...).
After some debugging I am still not sure though why it happens only with smaller files. I didn't tested with exact 1MiB file but it happens with ~900KiB and smaller files but not with an 1070KiB one and bigger...

The attached patch is a possible solution but it may does not fix the root of the problem....

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

Okay, didn't happen first time i tried it, but after multiple renames, refreshed, and changing that setting, it crashed.
And now it crashes every time i try to open it.
Debug build, rev 1755.

Thrown: ShareException: File Not Available
terminate called after throwing an instance of 'dcpp::ShareException'
  what(): ShareException: File Not Available
Adding new directory test

Changed in dcplusplus:
status: New → Confirmed
Revision history for this message
poy (poy) wrote :

i'm guessing this will fix itself when bug 210727 is fixed (ie, when hashing is only allowed to start after shared dirs have been browsed for new files)?

Revision history for this message
eMTee (realprogger) wrote :

Right, this way of the crash could be eliminated with solving 210727, but the exception still should be handled somehow since it can crash another way (like when one of the dupe files are not accessible, locked, etc...)

Revision history for this message
poy (poy) wrote :

i don't think so, there is no disk access involved here; all it does is compare paths to its internal cache. so just solving the actual root cause (probably bug 210727) should be enough.

Revision history for this message
eMTee (realprogger) wrote :

hmm... wouldn't ShareManager::findRealRoot() throw the exception if the matched file isn't accessible?

Revision history for this message
poy (poy) wrote :

right it checks for file existence, i didn't see that... so adding the try/catch does make sense.

Changed in dcplusplus:
status: Confirmed → Fix Committed
security vulnerability: no → yes
visibility: public → private
security vulnerability: yes → no
visibility: private → public
Revision history for this message
poy (poy) wrote :

Fixed in version 0.760.

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.