On Mon, 9 Mar 2026 12:56:14 GMT, Joel Sikström <[email protected]> wrote:
> Hello, > > In java.instrument native libinstrument JavaExceptions.c, the fallback > InternalError static sFallbackInternalError is created during VM or agent > initialization and is stored as a JNI local reference (NewObject via HotSpot > jni_NewObject to JNIHandles::make_local). Agent initialization runs under > JvmtiThreadEventMark in JvmtiExport::post_vm_initialized, which establishes a > JNI handle scope that is popped when the mark goes out of scope after the > VMInit callback returns. This allows sFallbackInternalError to outlive the > local handle block it was allocated in, leaving a dangling reference in a > static variable. In low-memory conditions, when creating a new InternalError > fails and the code falls back to sFallbackInternalError, the stored handle > has likely been cleared or reused, causing fallback exception creation or > throwing to fail. > > To make the fallback InternalError persistent, I suggest we allocate it in > global storage using JNI's NewGlobalRef. Since this fallback should be always > present, I don't think we should deallocate it. Simultaneously, I suggest we > enhance the return types a bit by using JNI_FALSE and JNI_TRUE instead of the > implicitly converted value from the comparison check. The first NULL-check > for the localRef isn't strictly needed as NewGlobalRef is well-defined in > taking in NULL as an argument, but I suggest we be explicit here to make it > easier for the reader to understand what's going on. > > Testing: > * Local testing in lldb to see that we always have access to a well-defined > fallback in different calls to JPLISAgent.c functions. > * Running through Oracle's tier1-4 Needs a copyright update. Otherwise looks good. Thanks for tracking down this long standing issue. ------------- PR Review: https://git.openjdk.org/jdk/pull/30141#pullrequestreview-3916438058
