[FLASH-USERS] XFlash Bug Fixes

James Guillochon jfg at ucolick.org
Mon Oct 20 11:13:44 EDT 2008


There is an issue in "determine_file_version.pro" on line 44 (I just 
checked the FLASH 3.1 distro), that H5D_GET_TYPE statement doesn't have 
a corresponding close statement. The other issue was that the H5F_CLOSE 
command should appear outside of the if-else since the file is opened 
outside of the if-else.

I'm looking at "file_information.pro" and I see that there are a couple 
of missing close statements there as well, specifically lines 148 & 149 
which have no close statements.

James Guillochon
Department of Astronomy & Astrophysics
University of California, Santa Cruz
jfg at ucolick.org

Seyit Hocuk wrote:
> One more thing,
> 
> I think you might mean "file_information.pro" instead of 
> "determine_file_version.pro", because only place where
> "H5T_CLOSE" and "H5D_GET_TYPE" are appearing are in the files 
> "file_information.pro" and "read_amr.pro".
> 
> 
> 
> 
> James Guillochon wrote:
>> Hi guys,
>>
>> Some missing code in one of the XFlash support routines was causing me 
>> intermittent problems for a long time, so I figured I'd share the fix 
>> in case anyone else was getting the same problem. Basically, whoever 
>> wrote the routine forgot to include a couple H5_CLOSE (such as 
>> "H5T_CLOSE, datatype") commands, which are necessary to avoid memory 
>> leaks! The omissions I found were in the determine_file_version.pro 
>> and read_amr.pro routines, both essential to XFlash. Here's the 
>> location of the missing commands:
>>
>> determine_file_version.pro:
>> Missing "H5T_CLOSE, datatype" after "H5D_GET_TYPE", should be inserted 
>> after "H5D_CLOSE, dataset" line.
>> "H5F_CLOSE" command appears inside if statement, it should be OUTSIDE 
>> the if statement, otherwise it isn't guaranteed to execute!
>>
>> read_amr.pro:
>> "H5F_CLOSE" command appears inside if statement, it should be OUTSIDE 
>> the if statement.
>>
>> This was causing me a huge headache and a memory corruption issue 
>> which would rear itself only occasionally, but would result in the 
>> wrong file being read! Very annoying when you're looping over hundreds 
>> of dumps...
>>
> 
> 
> !DSPAM:10135,48fc6d8022189021468!
> 



More information about the flash-users mailing list