Closed mattjala closed 10 months ago
This seems like it might be a bug in the connector itself, as the DAOS VOL for example doesn't have a "get object" callback defined and doesn't seem to have this problem. Is there a particular test or application where you ran into this?
This seems like it might be a bug in the connector itself, as the DAOS VOL for example doesn't have a "get object" callback defined and doesn't seem to have this problem. Is there a particular test or application where you ran into this?
It comes up for a few different tests in h5py's test suite. Specifically, the group test test_get_class
, which invokes H5O_get_info_by_name1
.
Full stack to the segfault:
H5Oget_info_by_name1
H5O__get_info_old
- H5VL_object_data
H5VL_native_token_to_addr
H5VL__native_get_file_addr_len
- H5VL_native_get_file_struct
H5F_sizeof_addr
H5O__get_info_old
calls H5VL_object_data()
, which returns a vol_obj->data
pointer that gets cast to H5F_t*
in H5VL_native_get_file_struct
. The actual type of data
is RV_object_t*
.
Ah ok, the issue is that the library doesn't currently check that the native VOL connector is being used when calling the old, now-deprecated API routines like H5Oget_info_by_name1
. They won't ever work with non-native VOL connectors and shouldn't be called with them. However, if this works around the issue it's probably fine, but I wouldn't count on being able to ever call those old routines with non-native VOL connectors.
This callback pointer being defined avoids the library's default behavior of grabbing the 'data' field and later assuming it can be safely cast to H5X_t*, leading to memory access errors.