H5Web both online and in VSCode hang indefinitely

[Blackclaws]

Describe the bug

I have an H5 result file of a test series that fails to load in both H5Web and VSCode extensions. The file size is 5Mb but I'm getting pretty much infinite loading screens (5 min + and counting with the occasional spin of the loading icon)

Unfortunately I cannot share the file itself as it contains information I cannot share.

Is there any way I could go about debugging this to find out what's actually blocking the read here?

[Blackclaws]

My guess is that the h5 file itself is problematic as h5dump also hangs indefinitely so its probably something I'll need to debug on the writing end of things.

[Blackclaws]

So I've made a minimal reproducible example. Since I can open the file again with PureHDF but not with h5dump or h5web I'm suspecting it might be some issue related to spec conformance.

Interestingly enough I can produce a file that opens in h5web but not in h5dump. Only difference to the main repro file being that the one that doesn't open in h5web either contains an additional "Nx_class" = "Nxentry" attribute on many classes. Maybe this also points towards a bug here or points to the fact that the file itself is fine per se but can't be read completely?

Minimal repro files attached:

repro.zip

[bmaranville]

With reproducible.h5 in your zip above, I get a hang in h5dump at the same place as in h5wasm... when reading the attribute value NX_class from the first group channel_0. Interestingly, h5py will open the file but will also hang for me when reading that attribute. I put some debug statements in a local build of h5wasm and found that it is not completing the call to H5Aread in the hdf5 C api. It is successfully opening the attribute but the read fails.

It seems like either your file is invalid or there is a problem in the HDF5 C code.

How are you creating these files?

[Blackclaws]

The files are written using PureHDF, I've also opened an issue there (see related issue) about this happening. They are two possibilities I see, its a writing issue where PureHDF is not writing spec conformant H5 files, or its a reading issue on HDF5 C's side where it can't read some spec compliant h5. I'm not deep enough in the internals of either of those to really comment, so I hope that someone more familiar can take a dive, which the author of PureHDF is also doing on their side I think.

[axelboc]

If it's a problem with the HDF5 library, you'll find a more knowledgeable crowd on the HDF Forum. Don't hesitate to report back here, though.

[Blackclaws]

It was indeed a write error in PureHDF and it was solved over there :)