H5Pset_est_link_info regression in 1.13.1?

HDF5 Library
1

Greetings!

Given the following small program setting the estimated link info in HDF5:

#include <assert.h>
#include "hdf5.h"

int main() {
        hid_t file_id, group_id, plist_id, flist_id;
        herr_t res;

        flist_id = H5Pcreate(H5P_FILE_ACCESS);
        assert(flist_id != H5I_INVALID_HID);
        res = H5Pset_libver_bounds(flist_id, H5F_LIBVER_LATEST, H5F_LIBVER_LATEST);
        assert(res >= 0);

        file_id = H5Fcreate("test.h5", H5F_ACC_TRUNC, H5P_DEFAULT, flist_id);
        assert(file_id != H5I_INVALID_HID);

        plist_id = H5Pcreate(H5P_GROUP_CREATE);
        assert(plist_id != H5I_INVALID_HID);
        res = H5Pset_est_link_info(plist_id, 570, 100);
        assert(res >= 0);

        group_id = H5Gcreate(file_id, "g", H5P_DEFAULT, plist_id, H5P_DEFAULT);
        assert(group_id != H5I_INVALID_HID);

        H5Gclose(group_id);
        H5Pclose(plist_id);
        H5Fclose(file_id);
        H5Pclose(flist_id);
}

Seems to fail when compiled with HDF5 1.13.1 like the following:

a.out: H5Omessage.c:2054: H5O_msg_flush: Assertion `mesg->raw_size < 65536' failed.

According to the documentation, each of the two arguments to H5Pset_libver_bounds is limited to 64k individually, and both 570 and 100 should be well within bounds. Using H5Pset_est_link_info(plist_id, 569, 100) works without a crash.

This is on Ubuntu 20.04, using GCC 9.4.0, with hdf5-1.13.1 using autotools. uname -a:

Linux bbd-7z0jwl2 5.4.0-107-generic #121-Ubuntu SMP Thu Mar 24 16:04:27 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

I’d appreciate any feedback if this is a bug or just us misusing the API!

Thanks,
Matthias

1 Like
2

Yep, very interesting!

3

Hi!

This is a bug. The size is inappropriately tripping an assert when the file is closed and the group is flushed to disk. We’re looking into it and hope to have more infor or a fix soon.

1 Like
4

Thank you for the confirmation. This was tripping up one of our unit tests, thanks also to @mario for noticing.

1 Like
5

FWIW, this bug appears to have been around for a very long time. It’s in the 1.8 branch, too. I don’t think we’ll get a fix into 1.12.2 since that release process is just about done, but hopefully we’ll get something into 1.10.9, which should come out next month sometime.

6

Github issue here: