Test failure while building 1.10.2-snap10 with debug / trace enabled

With the following configuration, build and test commands:

+ eval CC=mpicc CXX= FC=mpif90 cmake \
-DCMAKE_INSTALL_PREFIX=/home/greenc/work/cet-is/test-products/hdf5/v1_10_2_snap10/Linux64bit+3.10-2.17-e17-mpich-debug \
-DHDF5_BUILD_CPP_LIB:BOOL=OFF -DHDF5_BUILD_FORTRAN:BOOL=ON -DHDF5_ENABLE_PARLLEL:BOOL=ON -DHDF5_ENABLE_Z_LIB_SUPPORT:BOOL=ON \
-DCMAKE_CXX_STANDARD=17 -DCMAKE_BUILD_TYPE=Debug -DHDF5_ENABLE_USING_MEMCHECKER:BOOL=ON -DHDF5_MEMORY_ALLOC_SANITY_CHECK:BOOL=ON \
-DHDF5_ENABLE_DEBUG_APIS:BOOL=ON -DHDF5_ENABLE_TRACE:BOOL=ON -DHDF5_BUILD_HL_LIB:BOOL=OFF \
/home/greenc/work/cet-is/test-products/hdf5/v1_10_2_snap10/source/hdf5-1.10.2-snap10
+ make -j 20
+ ctest -j 20 --output-on-failure

The following tests fail:

The following tests FAILED:
        577 - H5REPACK-add_userblock (Failed)
        578 - H5REPACK-add_userblock_DFF (Failed)
Errors while running CTest

Test output:

255/1150 Test #577: H5REPACK-add_userblock .......................................***Failed    0.02 sec
H5tools-DIAG: Error detected in HDF5:tools (1.10.2) thread 0:
  #000: /home/greenc/work/cet-is/test-products/hdf5/v1_10_2_snap10/source/hdf5-1.10.2-snap10/tools/src/h5repack/h5repack_copy.c line 328 in copy_objects(): Could not 
copy user block. Exiting...
    major: Failure in tools library
    minor: error in function
  #001: /home/greenc/work/cet-is/test-products/hdf5/v1_10_2_snap10/source/hdf5-1.10.2-snap10/tools/src/h5repack/h5repack_copy.c line 1377 in copy_user_block(): HDopen
 failed input file </home/greenc/work/cet-is/test-products/hdf5/v1_10_2_snap10/build/Linux64bit+3.10-2.17-e17-mpich-debug/tools/test/h5repack/testfiles/ublock.bin>
    major: Failure in tools library
    minor: error in function

741/1150 Test #578: H5REPACK-add_userblock_DFF ...................................***Failed    0.91 sec

Strangley, these failures do not occur with a more normal -DCMAKE_BUILD_TYPE=RelWithDebInfo build, even though about twice as many tests are executed in that case.

We’re trying to trace a really hairy failure in an application that uses parallel I/O with filters. Is there something else we should be doing to get there?

Thanks for any help.

I agree this is strange because the failure is a simple file open as read only. This should not be influenced by the build type, there must be an interaction with a different option and the file system.