mirror of
https://github.com/HDFGroup/hdf5.git
synced 2026-09-25 04:09:44 +03:00
Matt L
355f67ac37
* Close datatype IDs derived from the memory type in the JNI translate helpers The object-tree read/write helpers in h5util.c derive a base datatype from the memory type with H5Tget_super() for the variable-length, array and complex classes, but never closed it. Because an hid_t is not reclaimed when the native method returns, every read or write of such data leaked at least one datatype ID for the lifetime of the process, and nested types leaked one per level. This PR updates the helpers to close the derived type in their done: blocks, which covers both the success and the error paths, and to reset the id in the compound loops to avoid the potential for double closes. It also has the helpers release the class references that the per-element helpers look up on entry. These are local references, so they were reclaimed when the enclosing native method returned, but a compound read calls the helper once per member per element and held one set per call until then. Releasing them at the single exit bounds the count of references to the recursion depth. * Add CHANGELOG entry for the JNI datatype ID leak fix * Restrict the derived datatype close guards to strictly positive IDs hid_t 0 is not a valid datatype ID, so H5Tclose(0) would fail. * Revert "Restrict the derived datatype close guards to strictly positive IDs" An hid_t of 0 not being a valid ID is a property of the current H5I encoding rather than a documented guarantee, so the JNI helpers should not depend on it.