summaryrefslogtreecommitdiffstats
path: root/config
diff options
context:
space:
mode:
authorJohn Mainzer <mainzer@hdfgroup.org>2009-02-06 18:20:13 (GMT)
committerJohn Mainzer <mainzer@hdfgroup.org>2009-02-06 18:20:13 (GMT)
commit2933d2f80b01c5e46c0a8161b3bd82249ab0b289 (patch)
tree30d6d611afc55328787e08efd7a4a17fbe0c85f7 /config
parent7418c063568d22fab2d34bd07664da60f44cdf98 (diff)
downloadhdf5-2933d2f80b01c5e46c0a8161b3bd82249ab0b289.zip
hdf5-2933d2f80b01c5e46c0a8161b3bd82249ab0b289.tar.gz
hdf5-2933d2f80b01c5e46c0a8161b3bd82249ab0b289.tar.bz2
[svn-r16451] Repaired intermittant failure of the t_cache test in testpar.
The failure was caused by some over active sanity checking code in unlock_entry(). In essence the code did not consider the possibility that under certain, very unusual circumstances, an entry could be flushed to disk during the H5AC_unprotect() call. Instead, it simply failed if a dirty entry was marked clean after the call to H5AC_unprotect(). This bug in the test code was exposed by recent changes to the default cache configuration made as part of the "metadata blizard" bug fix. Fixed the bug by adding code to detect when an entry is flushed during the call to H5AC_unprotect(), and not trigger a failure if a dirty entry is marked clean after a call to H5AC_unprotect() if the entry has been flushed. In passing also found and fixed another test bug in which expunged entries were erroneously marked as dirty in the test code's independant register of entry status. Tested parallel on Phoenix (AMD64 Linux) and Jam. Also ran t_cache manually hundreds of times looking for intermittant failures. Larry kindly tested (parallel) on Mercury.
Diffstat (limited to 'config')
0 files changed, 0 insertions, 0 deletions