summaryrefslogtreecommitdiffstats
path: root/windows
diff options
context:
space:
mode:
authorJohn Mainzer <mainzer@hdfgroup.org>2008-01-25 19:06:09 (GMT)
committerJohn Mainzer <mainzer@hdfgroup.org>2008-01-25 19:06:09 (GMT)
commit5342c5451a53ed0be6d4261f71e136bd176543d5 (patch)
treea2be566002b71e68bd1b6813bee9f786bfbc6dfd /windows
parent4677bbcfbde6dadac3cc09a5e056c8b805a1f404 (diff)
downloadhdf5-5342c5451a53ed0be6d4261f71e136bd176543d5.zip
hdf5-5342c5451a53ed0be6d4261f71e136bd176543d5.tar.gz
hdf5-5342c5451a53ed0be6d4261f71e136bd176543d5.tar.bz2
[svn-r14458] Fixed coredump under production 64-bit solaris.
As best I can tell, H5C_make_space_in_cache() was accessing memory that had been deallocated -- however the bug was easy to mask, and jumped around even in different runs of the same executable. While I was never able to generate a definitive test case that exposed exactly where the core dump occured, I was able to generate print statement traces which made it clear that I was accessing freed memory. In any case, reworking the code to avoid the reference to freed cache entries seems to have fixed the problem. Tested serial production on Phoenix, and commit tested. Also, partial tests Linew.
Diffstat (limited to 'windows')
0 files changed, 0 insertions, 0 deletions