mirrors/hdf5
2
0
Fork 0
mirror of https://github.com/HDFGroup/hdf5.git synced 2026-09-25 04:09:44 +03:00
Code Issues Packages Projects Releases Wiki Activity

Close datatype IDs derived from memory type in the JNI translation helpers (#6594)

Browse Source 
* 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.
This commit is contained in:
Matt L
2026-09-11 09:59:03 -05:00
committed by GitHub
parent 4ee8adc29c
commit 355f67ac37
4 changed files with 292 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
release_docs/CHANGELOG.md
+6
View File
@@ -104,6 +104,12 @@ We would like to thank the many HDF5 community members who contributed to this r
## Java Library
### Fixed datatype ID leaks when reading or writing nested datatypes through the JNI
The object-tree read and write helpers in the JNI derived 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 a native method returns, every read or write of such data leaked at least one datatype ID for the lifetime of the process, and a nested type leaked one per level. The helpers now close the derived type on both the success and error paths.
Fixes GitHub issue #6592
## Configuration
### Fixed version handling in installed CMake package version configuration file