diff options
author | Quincey Koziol <koziol@hdfgroup.org> | 2002-06-01 03:11:34 (GMT) |
---|---|---|
committer | Quincey Koziol <koziol@hdfgroup.org> | 2002-06-01 03:11:34 (GMT) |
commit | 44a72a6777520034f87f712697ce05de5929f288 (patch) | |
tree | a8ef3c925a71a46e83bb82783aed0fcfdc33d6a0 /perform | |
parent | 8249ec87a2170c52baf8c33c51c1743a4ead5ec7 (diff) | |
download | hdf5-44a72a6777520034f87f712697ce05de5929f288.zip hdf5-44a72a6777520034f87f712697ce05de5929f288.tar.gz hdf5-44a72a6777520034f87f712697ce05de5929f288.tar.bz2 |
[svn-r5502] Purpose:
Test Bug Fix
Description:
Under certain [obscure] circumstances, an object header would get paged out
of the metadata cache, and when it was accessed again and brought back into
the cache, and immediately had additional metadata added to it (an
attribute, usually, or perhaps adding an object to a group), and needed to
be extended with a continuation message, but there was no room in any
existing object header chunks for the continuation message and an existing
object header message needed to be moved to the new object header chunk (I
told you it was obscure :-), the object header message moved to the new
chunk (not the new metadata being added) would get corrupted. *whew* :-)
Solution:
Actually copy the "raw" object header message information of the object
header message being moved to the new chunk, instead of relying on the
"native" object header message information being re-encoded when the object
header is flushed. This is because when an object header is paged out of
the metadata cache and subsequently brought back in, the "native"
information pointer in memory is reset to NULL and only the "raw"
information exists.
[Actually, this additional testing doesn't trigger the bug, which needs
_lots_ of objects to be created and accessed, but it does execise the
object header continuation code more than other tests in the library.]
Platforms tested:
Solaris 2.7 (arabica) & FreeBSD 4.5 (sleipnir)
Diffstat (limited to 'perform')
0 files changed, 0 insertions, 0 deletions