jash-kothari-forks / libtorrent

Automatically exported from code.google.com/p/libtorrent
Other
0 stars 0 forks source link

file_error_alert when disabling OS caching for reading/writing #272

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
after io errors with disable_os_cache were fixed in #251 i have made several 
tests among our users. and found following issues

when i set
    settings.disk_io_write_mode = session_settings::disable_os_cache;
    settings.disk_io_read_mode = session_settings::enable_os_cache;
users get pretty much of
ERROR_SHARING_VIOLATION
32 (0x20)
The process cannot access the file because it is being used by another process.

when i try
    settings.disk_io_read_mode = session_settings::disable_os_cache;
    settings.disk_io_write_mode = session_settings::enable_os_cache;
users start getting
ERROR_INVALID_PARAMETER
87 (0x57)
The parameter is incorrect.

and sure when i set both to disable_os_cache, users receive both 32 and 87 
errors

i was unable to reproduce any of these errors. and this is really troublesome 
to track them down. meanwhile disable_os_cache is extremely useful for windows 
at large download speeds, because with enable_os_cache windows' cache grows 
huge until system becomes completely unresponsible

Original issue reported on code.google.com by rain87...@gmail.com on 25 Nov 2011 at 7:46

GoogleCodeExporter commented 9 years ago
i was testing on latest 15.9 release

Original comment by rain87...@gmail.com on 25 Nov 2011 at 7:48

GoogleCodeExporter commented 9 years ago
I'm able to reproduce the error and I dig a little bit into the code up to the 
line that generates the error (the 87 one that is the most frequent).

Here is what I found:
- The torrent that shows the error (very frequently) is
https://bugs.launchpad.net/qbittorrent/+bug/871328/+attachment/2532650/+files/Ca
ll_of_Juarez_The_Cartel-SKIDROW.6647656.TPB.torrent
The torrent download is pretty at the beginning (1.5%)
- the error (87) appears when the async_hash function (last lines of the 
torrent::async_verify_piece in file torrent.cpp) triggers the disk_io_job::hash 
case in the disk_io_thread::operator function (disk_io_thread.cpp). Here is the 
backtrace up to the line (line 500, "num_read = m_storage->readv(bufs, slot, 
ph.offset, num_blocks);") that sets the m_error code if I do a "step over"

0   libtorrent::piece_manager::hash_for_slot    storage.cpp 500 0x689e96    
1   libtorrent::piece_manager::hash_for_piece_impl  storage.cpp 1908    0x690146    
2   libtorrent::disk_io_thread::operator()  disk_io_thread.cpp  1945    0x832fb3    
3   boost::detail::thread_data<boost::reference_wrapper<libtorrent::disk_io_thread
> >::run    thread.hpp  87  0x842382    
4   boost::`anonymous namespace'::thread_start_function thread.cpp  177 0x921e80    
5   _beginthreadex  MSVCR90D        0x1023dec3  
6   _beginthreadex  MSVCR90D        0x1023de59  
7   BaseThreadStart kernel32        0x7c80b729

I see the error appearing on many "piece_index" value (parameter of the 
async_hash function) but I don't see any piece_index value twice so I don't 
know if the error is related to specific pieces and I'm not lucky or the error 
is somehow not related to specific pieces.
Here is the list if the piece_index values which generate the error so far:
1716, 988, 702, 890, 819, 1664, 1624, 1014, 934, 535, 628, 992, 971, 1705, 522, 
539, 1005

My knowledge of the libtorrent code is almost zero so I hope those information 
could help someone else to figure out which is the problem. I will be available 
for any further information about the above description.

I got another torrent that gives another error (I suppose the 32) but at a 
really low rate and I'm not yet able to catch the right code location... I will 
continue to try to found it... 

Original comment by paolo.za...@tiscali.it on 27 Dec 2011 at 3:51

GoogleCodeExporter commented 9 years ago
I proceed a little bit down into the code and I found that the problem comes 
from the function storage::read_unaligned (storage.cpp, line 1504) where readv 
function is called with a negative aligned_start value. Indeed the 
aligned_start variable is defined as "const int" but it should be "const int64" 
or "const size_type", am I wrong?

Original comment by paolo.za...@tiscali.it on 27 Dec 2011 at 4:56