Windows crash on exit when callback to H5Aiterate1 throws an exception

[krisfed]

Describe the bug
We see a crash on program exit when callback to H5AIterate1 throws an exception

Expected behavior
No crash

Platform

• HDF5 version: 1.14.4.3
• OS and version: Windows 10

Additional context
I was able to reproduce the crash in a simplified standalone code as follows:

#include <iostream>
#include <stdexcept> // For std::runtime_error

#include "hdf5.h"

herr_t iterateFunc(hid_t locID, const char* attName, void* info)
{
	std::cout << "attribute name: " << attName << std::endl;

	// throw an error
	throw std::runtime_error("Error in iterate func");

	return 0;
}

int main() {

	// open HDF5 file
	hid_t fileID = H5Fopen("myFile.h5", H5F_ACC_RDONLY, H5P_DEFAULT);
	std::cout << "fileID after H5Fopen: " << fileID << std::endl;

	herr_t status = 0;
	unsigned int attrIdx = 0;

	// iterate over the attributes
	try {
		status = H5Aiterate1(fileID, &attrIdx, (H5A_operator1_t)iterateFunc, NULL);
		std::cout << "status after H5Aiterate1: " << status << std::endl;
	} catch (const std::runtime_error& e) {
		std::cout << "EXCEPTION: " << e.what() << std::endl;
	}

	// close HDF5 file
	status = H5Fclose(fileID);
	std::cout << "Status after H5Fclose: " << status << std::endl;

	return 0;
}

• It can be reproduced on any file with attributes
• The iterate callback must throw an exception
• It happens on program exit, not during H5AIterate1 call
• We only see the crash on Windows, but both on Windows and macOS we see this kind of output in the terminal:

HDF5: infinite loop closing library
L,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

[derobins]

If you change iterateFunc() to call abort(), exit(), and/or _exit(), do you get the same behavior?

[krisfed]

@derobins abort() looks different:

After clicking "Abort":

While exit() and _exit() look somewhat similar to the original issue (getting same "unhandled exception" and "infinite loop closing library") :

Note though that in the original reproduction steps I catch the exception and I get to the H5Fclose line before the crash happens. The full output of the original code is:

fileID after H5Fopen: 72057594037927936
attribute name: creation_date
EXCEPTION: Error in iterate func
Status after H5Fclose: 0
HDF5: infinite loop closing library
      L,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

I will check what abort/exit does in our whole workflow in our application as well.

[krisfed]

In our complete workflow I get a similar-looking crash with either abort(), exit(), or _exit().

The relevantly-looking part of the stack trace is as follows (same in all four cases):

[  8] 0x00007ff94e761881 raise+00000481 at C:\windows\System32\ucrtbase.dll+465025
[  9] 0x00007ff94e762851 abort+00000049 at C:\windows\System32\ucrtbase.dll+469073 
[ 10] 0x00007ff895451c7a H5_term_library+00001258 at <...>\bin\win64\hdf5.dll+7290
[ 11] 0x00007ff94e7042d6 execute_onexit_table+00000342 at C:\windows\System32\ucrtbase.dll+82646 
[ 12] 0x00007ff94e7041fb execute_onexit_table+00000123 at C:\windows\System32\ucrtbase.dll+82427
[ 13] 0x00007ff94e7041b4 execute_onexit_table+00000052 at C:\windows\System32\ucrtbase.dll+82356
[ 14] 0x00007ff8957ecb09 H5Z_xform_noop+00002313 at <...>\bin\win64\hdf5.dll+3787529
[ 15] 0x00007ff8957ecc2e H5Z_xform_noop+00002606 at <...>\bin\win64\hdf5.dll+3787822

[bmribler]

From @fortnern: This is expected behavior. The library is designed with the assumption that the callback will return (possibly with an error code) and the library will be able to clean everything up before returning from the top level API call.