Hi All,
I figured I would send this out to the developers before it goes public.
Not too long ago a user on the mailing list reported seeing this error
while doing a simple RMS calc in ptraj:
ERROR in safe_malloc: Error in alloc of -8 bytes
It turns out this stems from the recent code changes to ptraj where
the stop value of a trajectory was being set to -1 if the number of
frames could not be calculated, either due to a compressed or a
corrupted file. The maximum frames to be read was then assigned a
value of -1. Unfortunately many ptraj actions allocate memory ahead of
time based on the number of frames to be read in, so a malloc of a
negative number was being attempted. What's interesting is that this
doesn't generate an error message on some systems; the negative number
is interpreted as an unsigned integer and hence given a HUGE value and
so way too much memory (1.3 GB in my test) would be allocated. On this
users system the negative number was not converted in this way and so
generated the error.
I am attaching a patch that will always set the number of frames and
so avoid this issue. In the case of gzipped trajectories the
uncompressed file size is stored in the last 4 bytes of the gzip file,
and so the number of frames can be calc'd. Unfortunately bzip2 and zip
files don't have something similar, so they need to be run through
bzcat/unzip to get their uncompressed file size, which will add to the
processing time. There is really no way around this right now short of
recoding all ptraj actions that use allocation based on maxFrames to
do dynamic memory allocation instead.
Let me know if there are any problems with the patch.
-Dan
--
-------------------------
Daniel R. Roe
Postdoctoral Associate
SAS - Chemistry & Chemical Biology
610 Taylor Road
Piscataway, NJ 08854
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu May 27 2010 - 14:00:03 PDT
