On Mon, 30 Oct 2023 15:57:23 GMT, Andrew Haley <a...@openjdk.org> wrote:
> The bug here is a thinko in `ScopedValue.scopedValueBindings()`. > > If the JVM runs out of resources, we throw a `VirtualMachineError`. Running > out of resources can happen at almost any time, and can happen while > `ScopedValue`'s internal structures are being modified, leaving them in an > inconsistent state. We detect when a `VirtualMachineError` happens and walk > the stack to find the most-recent set of `ScopedValue` bindings. > > When we crate a new `Thread`, we push a sentinel frame onto the stack that we > can find in the case that we threw a `VirtualMachineError`. Threads created > by the native invocation interface (rather than by Java threads) don't have > that sentinel, so a search for it returns null. Therefore, in the rare cases > where we have to do a stack walk, we must check for both > `NEW_THREAD_BINDINGS` (the sentinel) and `null`. We weren't doing that, we > were only checking for null. This pull request has now been integrated. Changeset: ee6f25b5 Author: Andrew Haley <a...@openjdk.org> URL: https://git.openjdk.org/jdk/commit/ee6f25b5072a26254f79381a92216357d9f391f9 Stats: 67 lines in 2 files changed: 62 ins; 1 del; 4 mod 8319120: Unbound ScopedValue.get() throws the wrong exception Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/16422
