fox88, on 13 September 2018 - 02:15 PM, said:
That just rephrases the original statement as a question.
But it was expected to get a detailed explanation: which methods, what line numbers, what conditions - and so on for 0.50b code.
This is not a huge request, because a problem must be clearly understood before getting fixed.
In current code base of 0.50b, in CPartFile::FlushBuffer of PartFile.cpp, line 4825~4826, if the handle of the specific CPartFile is being manipulated by ReadFile call of line 316 in CUploadDiskIOThread.cpp, it's possible that the Write call in PartFile.cpp line 4826 will be written to a wrong position.
Edit: I suspect it may related to some unspeakable downloaded data corruption somehow.
Edit2: The experiments on my codebase gave more credibility on my above theory. By writing a series of consecutive downloaded buffer blocks as a whole to the disk in one loop, and leaving the costly memory release operations after the loop, the mysterious download corruptions here and there are completely vanished, at least in 1 day and 4 hours running eMule with heavy downloads (32 files finished).
It doesn't mean that the thread conflicts are gone, it just narrowed down the window that could cause the conflicts. So it's probably a real bug after introducing asynchronous uploading, and it can be fixed.
Edit3: Back to 0.50b codebase and refer to the correct line.
This post has been edited by Enig123: 14 September 2018 - 05:01 AM