Repository navigation
Conversation
kstat_ctl_t declares kc_chain as a kstat_t pointer, but KstatCtl mapped it as an inline Kstat structure, so JNA computed the structure as 200 bytes against the native 24 (32 on Solaris 11.4). Because a Structure passed by reference is written before and read after every call, each kstat_chain_update, kstat_lookup, kstat_read, and kstat_close wrote 176 bytes past the end of the block kstat_open() allocated, reverting adjacent heap to its contents at the previous call. Map kc_chain as a Pointer and add KstatCtl.chain() to return the chain head as a Kstat, using a new Kstat(Pointer) constructor that next() now shares. Solaris 11.4's trailing kc_private field is private to libkstat and deliberately left unmapped; the structure only wraps the pointer kstat_open() returns, so the three-field mapping is a safe prefix there. Verified on Solaris 11.4 SPARC under libumem with UMEM_DEBUG=default: size 24, a full walk of the 4675-entry chain, and 1000 update/lookup/read cycles plus kstat_close with no allocator errors. Fixes java-native-access#1740
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
kstat_ctl_tdeclareskc_chainas akstat_tpointer, butKstatCtlmapped it as an inlineKstat(ByValue) Structure, so JNA computed the structure as 200 bytes against the native 24 (32 on Solaris 11.4). Because a Structure passed by reference is written before and read after every call, eachkstat_chain_update,kstat_lookup,kstat_read, andkstat_closewrote 176 bytes past the end of the blockkstat_open()allocated, reverting adjacent heap to its contents at the previous call.This PR maps
kc_chainas aPointerand addsKstatCtl.chain()to return the chain head as aKstat, using a newKstat(Pointer)constructor thatnext()now shares. Solaris 11.4's trailingkc_privatefield is private to libkstat and deliberately left unmapped; the structure only wraps the pointerkstat_open()returns, so the three-field mapping is a safe prefix there.This is technically a breaking change: anyone who has mapped the previous
kc_chainvalue will fail compilation. However, that value has never worked, it's a 64-bit timestamp, not a pointer, so the blast radius of this change is probably near-zero.Existing native code used just the intended pointer value, ignoring JNA's claim it was a timestamp, so this effectively was a race condition if adjacent memory was used by another process: rare in libc malloc handling, common in umem handling.
Fixes #1740