search

HDFGroup / vol-rest

HDF5 REST VOL Connector
Other
5 stars 8 forks source link

Add stub for connector get object callback #77

Closed mattjala closed 10 months ago

mattjala commented 11 months ago

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.

jhendersonHDF commented 11 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?

mattjala commented 11 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?

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*.

jhendersonHDF commented 11 months ago

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.