Describe the bug
Similar to #520. It is possible in the openPMD API to create workflows where an OPEN_FILE IO task is issued for a file that is already open. HDF5 refuses to reopen files that are already opened:
I am not sure what exactly is causing the error but a common mistake that people do in Jupyter notebook is they forget to close the
h5before trying to access it again.
So tryf.close()and try opening it again.
(see here)
To Reproduce
The same code as in #520 can be used to reproduce the issue, simply switch "3_write_serial%T.bp" out for "3_write_serial%T.h5". Fails with:
HDF5-DIAG: Error detected in HDF5 (1.8.20) thread 0:
#000: H5G.c line 465 in H5Gopen2(): unable to open group
major: Symbol table
minor: Can't open object
#001: H5Gint.c line 318 in H5G__open_name(): group not found
major: Symbol table
minor: Object not found
#002: H5Gloc.c line 428 in H5G_loc_find(): can't find object
major: Symbol table
minor: Object not found
#003: H5Gtraverse.c line 859 in H5G_traverse(): internal path traversal failed
major: Symbol table
minor: Object not found
#004: H5Gtraverse.c line 639 in H5G_traverse_real(): traversal operator failed
major: Symbol table
minor: Callback failed
#005: H5Gloc.c line 383 in H5G_loc_find_cb(): object '0' doesn't exist
major: Symbol table
minor: Object not found
terminate called after throwing an instance of 'std::runtime_error'
what(): Internal error: Failed to open HDF5 group during path opening
Is there a read-only mode? Maybe it's open for RW?
There is, but it does not solve the issue. I tried replacing lines 364-368 of HDF5IOHandler.cpp with the following code
file_id = H5Fopen(name.c_str(),
flags,
m_fileAccessProperty);
if( file_id < 0 )
{
// try opening as read only
file_id = H5Fopen(name.c_str(), flags, H5F_ACC_RDONLY);
if ( file_id < 0 )
throw no_such_file_error("Failed to open HDF5 file " + name);
}
i.e., open the file in read-only mode if opening in read-write fails.
For some reason the minimal example that I gave in the initial bug description does not trigger the bug for me any more, I will try coming up with an alternative example. The bug still appears in the openPMD plugin for PIConGPU and can be mitigated with this workaround.
It seems this issue has been fixed with a temporary workaround? Should we close this or leave open until implementation of a proper solution? @ax3l
Oh yes, @guj fixed another issue with multiple flush on the same file by implementing an open-file lookup table: #643
One of the reasons we need Iteration::close() - to close these handles as soon as we want to get rid of them.
(note that Iteration::close() should not be implicit in ~Iteration()).
That's great, this means the HDF5 backend is now working from within the openPMD plugin in PIConGPU :)
Yes, we needed the same feature in WarpX, which triggered the bug fix :)
Fixed with #643
Most helpful comment
That's great, this means the HDF5 backend is now working from within the openPMD plugin in PIConGPU :)