Fixed H5Ovisit2 change of behavior between 1.10.11 and v1.14.4.3 #4958
Conversation
In H5O_get_info() of 1.10.11:
HDmemset(oinfo, 0, sizeof(*oinfo))
set oinfo->type to 0, which was also the value of H5O_TYPE_GROUP, so
oinfo->type accidentally had a correct value when the object was a group.
If oinfo->type were initialized to H5O_TYPE_UNKNOWN as it should be, the
application would have behaved the same way as with 1.14.3, whose H5O_get_info()
called H5O__reset_info2() that set oinfo->type to H5O_TYPE_UNKNOWN.
So, it was a case of coincidentally correct behavior in 1.10.11.
The fix is to assign the correct value to oinfo->type early on instead
of only when the requested info is H5O_INFO_BASIC. For that matter, probably
all or some of the fields being set in the H5O_INFO_BASIC block should be
changed the same way to prevent similar potential errors.
(GH HDFGroup#2136)
bmribler
requested review from
lrknox,
derobins,
byrnHDF,
fortnern,
jhendersonHDF,
qkoziol,
vchoi-hdfgroup,
glennsong09,
mattjala and
brtnfld
as code owners
There was a problem hiding this comment.
The previous code for this routine is correct. The root cause of this issue is the visit.fields parameter set in H5Ovisit2 / H5Ovisit_by_name2 should have the H5O_INFO_BASIC flag set.
Note that it's possible that the user may not want the information from H5O_INFO_BASIC, so the code in H5O_get_info may need to be refactored info a new H5O_get_info_real, and the object header protected in H5O__visit, so that there's less overhead in getting both the information that H5O__visit needs and the information the application wants in the object info struct.
Happy to have a short call if you'd like to talk about this.
|
Yeah, the user's app passed H5O_INFO_META_SIZE into H5Ovisit2. |
In H5O_get_info() of 1.10.11:
set oinfo->type to 0, which was also the value of H5O_TYPE_GROUP, so oinfo->type accidentally had a correct value when the object was a group.
If oinfo->type were initialized to H5O_TYPE_UNKNOWN as it should be, the application would have behaved the same way as with 1.14.3, whose H5O_get_info() called H5O__reset_info2() that set oinfo->type to H5O_TYPE_UNKNOWN. So, it was a case of coincidentally correct behavior in 1.10.11.
The fix is to assign the correct value to oinfo->type early on instead of only when the requested info is H5O_INFO_BASIC. For that matter, probably all or some of the fields being set in the H5O_INFO_BASIC block should be changed the same way to prevent similar potential errors.
(Fixes GH #4941)