[Mldonkey-bugs] [Bug #1173] array bounds violations in latest CVS on OS X 10.2 -> SIGBUS

[nobody]

=================== BUG #1173: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=1173&group_id=1409

Changes by: Anonymous user        Date: 2002-Sep-10 22:26

------------------ Additional Follow-up Comments ----------------------------
there are problems if the on-disk file size of a recovered file is
different from the file-size known on the donkey network: loops 
from 0 to file.file_nchunks end up having too few network chunks,
and the recovery can also lead to file.file_nchunks and the length
of the file.file_chunks array differing.   if the index is larger than
the array, mldonkey dies with SIGBUS on the mac os x 10.2 ppc platform.

if one does recover_temp and a file is recovered that had been put
into pause state because there was insufficient disk space to grow
the on-disk file to the full size found when starting the file download
in the first place, the current code will have a permanent disagreement
between what the donkey network believes is the file size, and what
the local mldonkey believes is the filesize.  this leads to program crashes.   

a fix should recognize that the on-disk file size is NOT canonical in
some circumstances, and that in those circumstances, the on-disk
chunks should be tested to see if they are PresentValid.  however,
the test should either grow the file to the network's idea of the
file size, or it should stop at disk-file EOF.   in either case, the
state held about the file size (and related info such as file.file_nchunks
and the chunk arrays) should be updated to a *correct* network size.

one possible approach might be to have a zombie file state which
recover_temp uses until it gets a "consensus view" about the
proper file size for a given MD4 file from the donkey network,
then do the size bookkeeping, then run the file through the current
recover_temp process.   or, "step 1: synthesize (or search) an ed2k:// link.  
step2:
start a download on that link.  step 3: validate the on-disk data, as
if it arrived after step 2.".



=================== BUG #1173: FULL BUG SNAPSHOT ===================


Submitted by: None                      Project: mldonkey, a free e-Donkey 
client
Submitted on: 2002-Sep-10 09:58
Category:  None                         Severity:  5 - Major                    
Bug Group:  None                        Resolution:  None                       
Assigned to:  None                      Status:  Open                           

Summary:  array bounds violations in latest CVS on OS X 10.2 -> SIGBUS

Original Submission:  hi -

there are cases where loops across file.file_nchunks in
donkey/donkeyOneFile.ml and donkey/donkeyClient.ml
fail because the loop index is used to reference arrays
that are not long enough.

e.g., (Array.length file.file_chunks) != file.file_nchunks
or (Array.length chunks) != (Array.length file.file_chunks)

this is easily triggered by removing files.ini and history.met,
restart, and "recover_temp".   entries in files.ini with "file_length = 0"
will also cause SIGBUS crashes because of array bounds problems throughout
the formerly secret code.

no fix yet, but lots of interesting stuff learned via Printf.printf / 
printf_string
sprinkled liberally...

why is this a problem in os x 10.2 and not other 
architectures/operating-systems,
including os x 10.1 & os x 10.0?

-- rottegift 

Follow-up Comments
*******************

-------------------------------------------------------
Date: 2002-Sep-10 22:26             By: None
there are problems if the on-disk file size of a recovered file is
different from the file-size known on the donkey network: loops 
from 0 to file.file_nchunks end up having too few network chunks,
and the recovery can also lead to file.file_nchunks and the length
of the file.file_chunks array differing.   if the index is larger than
the array, mldonkey dies with SIGBUS on the mac os x 10.2 ppc platform.

if one does recover_temp and a file is recovered that had been put
into pause state because there was insufficient disk space to grow
the on-disk file to the full size found when starting the file download
in the first place, the current code will have a permanent disagreement
between what the donkey network believes is the file size, and what
the local mldonkey believes is the filesize.  this leads to program crashes.   

a fix should recognize that the on-disk file size is NOT canonical in
some circumstances, and that in those circumstances, the on-disk
chunks should be tested to see if they are PresentValid.  however,
the test should either grow the file to the network's idea of the
file size, or it should stop at disk-file EOF.   in either case, the
state held about the file size (and related info such as file.file_nchunks
and the chunk arrays) should be updated to a *correct* network size.

one possible approach might be to have a zombie file state which
recover_temp uses until it gets a "consensus view" about the
proper file size for a given MD4 file from the donkey network,
then do the size bookkeeping, then run the file through the current
recover_temp process.   or, "step 1: synthesize (or search) an ed2k:// link.  
step2:
start a download on that link.  step 3: validate the on-disk data, as
if it arrived after step 2.".




No files currently attached


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=1173&group_id=1409