On Tue, 16 Dec 2025 18:47:34 GMT, Jorn Vernee <[email protected]> wrote:

> ASAN correctly detected a use-after-free in this test.
> 
> The issue is that an async `ScopedAccessError` is thrown while executing java 
> code as part of a JVMTI callback. This exception is meant to unwind out of a 
> scoped memory access, to prevent access to memory that has already been 
> freed. But, currently the native agent code is printing and clearing the 
> exception, which doesn't prevent the memory access from occurring, leading to 
> a use-after-free.
> 
> Ideally, the agent should propagate the exception to the place in the Java 
> code where the JVMTI event happens, but it is not possible to exit the 
> callback with a pending exception, and AFAICT there is no JVMTI API for 
> propagating async exceptions that are thrown during a JVMTI callback. So, the 
> only sane thing the test can do is exit the process, which is what I've 
> implemented here.
> 
> This fixes the test, but it leaves the larger question of how JVMTI agents 
> should deal with async exceptions unresolved.

This pull request has now been integrated.

Changeset: 821e9ff9
Author:    Jorn Vernee <[email protected]>
URL:       
https://git.openjdk.org/jdk/commit/821e9ff965cad52cdd26c08785312db49bcce539
Stats:     41 lines in 2 files changed: 27 ins; 5 del; 9 mod

8372493: [asan] java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java 
triggers heap-use-after-free

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/28853

Reply via email to