abort occurs only if display error message is enabled

[bansan85]

Describe the bug
After opening a buggy h5 file, app shows when closing:

HDF5: infinite loop closing library
      L,G_top,T_top,P,P,Z,FD,VL,VL,PL,E,SL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL
Debug Error!

This is fine. In H5_term_library (in H5.c), there is:

    if (pending) {
        /* Only display the error message if the user is interested in them. */
        if (func) {
            fprintf(stderr, "HDF5: infinite loop closing library\n");
            fprintf(stderr, "      %s\n", loop);
#ifndef NDEBUG
            abort();
#endif
        }
    }

But if I disabled output with H5Eset_auto2, the library doesn't abort anymore.

Is it fine that abort() is done only if display is enabled ? Shouldn't abort must be after if (func) instead of inside ?

If you confirm that it's a bug, I can easily write a fix.

Expected behavior
abort should always occurs.

Platform (please complete the following information)

• HDF5 version : 1.14.6
• OS and version: Windows 25H2
• Compiler and version: VS 2022
• Build system (e.g. CMake version) and generator (e.g. XCode, Ninja)

[mattjala]

Did your particular workflow depend on the abort behavior in a particular way, or is this purely an issue with regards to consistency? We're leaning towards removing the abort in this case entirely, so it would be helpful to hear if this provides some use in your case.

[bansan85]

You can remove the abort call. I made a custom h5 fuzzer to test my app that read h5 files. I found this misplaced abort while diagnosting the crash of my app after reading random data.