tst_h_dimscales with hdf5-1.10

[zerothi]

Please provide as much of the following information as you can, as applicable to the issue being reported. Naturally, not all information is relevant to every issue, but the more information we have to start, the better!

Environment Information

gcc-6.3.0
zlib-1.2.11
hdf5-1.10.0-patch1
I am doing a serial installation (no MPI).

64-bit, Linux, debian Jessie (fully upgraded)
Using autotools (attached config.log)

config.log.txt

Summary of Issue

After having compiled the netcdf-4 C library I issue make check and then this test fails:
FAIL: tst_h_dimscales
All other tests succeed.

For completeness sake, I have attached the log for the test:

tst_h_dimscales.log.txt

Steps to reproduce the behavior

The config.log should provide enough details. A "simple" ../configure ..., make, make check.

[WardF]

Is it possible to check if the test works with hdf5 1.8.18? I will try to recreate on my end with 1.10.x but for the time being we are still recommending people stick with the hdf5 1.8.x branch.

[zerothi]

I thought so too, but https://www.unidata.ucar.edu/blogs/news/entry/netcdf-4-4-1-1 indicated otherwise, hence I tested.

I have just done the same with 1.8.18, no problems.

[WardF]

Ok, I will attempt to recreate this issue locally and see if I can debug it; 4.4.1.1 fixed a very big issue with hdf5 1.10.x, in terms of broken backwards compatibility. But because of issues similar to what you've reported, we're still taking the approach of recommending 1.8.x; we have no reason to think 1.10.x is broken, it should work, but YMMV.

[winash12]

Is this issue fixed in NetCDF 4.5.0 ?

[ArchangeGabriel]

@winash12 No it’s not, just verified that right now.

[winash12]

@ArchangeGabriel - is that a show stopper ? Can I proceed to make install or not ?

[ArchangeGabriel]

Not sure. We do proceed on Arch.

But you could also use CMake apparently to solve this.

[WardF]

This issue is described in more detail here:

• Test failure building against hdf5 1.10.0 #244

In short, the failure is occurring in a test that uses the hdf5 API only, occurs when building with autotools + compiler optimization, and is the result of a variable in a for loop going from a good value (5) to a garbage value for no discernible reason while in a function in libhdf5. (see this comment specifically). I'm not entirely certain what we can do about it on our end other than disable the test for the time being, since it is not using the netCDF API or library, but I also don't want to ask our users to "live with it".

[ArchangeGabriel]

Just for the record, I confirm the issue is still present with 4.5.0 final but that switching to CMake makes it work.

[ArchangeGabriel]

Shouldn’t we close this in favour of #244?

[edhartnett]

Howdy all!

Note that this may be related to #505.

The tst_h_* tests are not part of netCDF, I wrote them as I learned HDF5 and implemented netCDF-4. They proved useful as they test HDF5 in the way that netCDF-4 expects it to work. So I would go ahead and ignore tst_h_dimscales failures until we can find the memory problem.

[WardF]

Fixed by #511.