I’ve been working on implementing instrumentation wrappers for HDF5 (standard wrapper library technique) and have encountered some strange behaviour with the ph5example.c sample. Our wrappers record trace records at function entry and exit, and in the event that the function being wrapped performs an I/O operation, they record that as well; this means we’re calling H5Iget_file_id inside these wrappers to find the appropriate file handle that goes with a H5Dread/write operation. Here’s the behaviour I’ve seen:
- If H5Iget_file_id is called in the wrapper to H5Dwrite, and a single run of ph5example performs both a collective write and a collective read, when we open the file for collective reading it has an invalid superblock.
- If we interpose an H5close/H5open pair between the collective write and collective read, everything works fine.
- Non-collective read/write do not have this problem.
- Replacing H5Iget_file_id with a simple cache mapping data set ids to file ids also works, though this is obviously not a great solution.
The calls to H5Iget_file_id should be safe according to the documentation–they’re by definition as collective as the calls to H5Dwrite that they’re in the wrappers for. Is this a bug or am I doing something that’s unsafe by design somehow?