[jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]
jvernee at openjdk.java.net
Thu Jul 15 11:06:13 UTC 2021
On Wed, 14 Jul 2021 00:50:44 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> src/hotspot/share/runtime/safepoint.cpp line 931:
>>> 929: // See if return type is an oop.
>>> 930: bool return_oop = nm->method()->is_returning_oop();
>>> 931: HandleMark hm(self);
>> I was seeing an `assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark` when the existing code allocates the Handle for `return_value` in the code down below. It seems to be a simple case of a missing handle mark, so I've added it here. (looking at the stack trace in the error log, the caller frame is native code, so I don't think we can expect the caller to have a HandleMark).
> How does native code reach a safepoint polling point?
The stack trace looks like this:
Current thread (0x000002a2489f0b50): JavaThread "Thread-4551" [_thread_in_Java, id=24920, stack(0x000000d9e0500000,0x000000d9e0600000)]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0xae6651] os::platform_print_native_stack+0xf1 (os_windows_x86.cpp:235)
V [jvm.dll+0xda3f25] VMError::report+0x1005 (vmError.cpp:739)
V [jvm.dll+0xda58ae] VMError::report_and_die+0x7fe (vmError.cpp:1549)
V [jvm.dll+0xda5fe4] VMError::report_and_die+0x64 (vmError.cpp:1330)
V [jvm.dll+0x4ceca7] report_vm_error+0xb7 (debug.cpp:282)
V [jvm.dll+0x6511be] HandleArea::allocate_handle+0x3e (handles.cpp:35)
V [jvm.dll+0xb8e334] ThreadSafepointState::handle_polling_page_exception+0x314 (safepoint.cpp:939)
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 639 c1 java.lang.invoke.LambdaForm$MH+0x000000080101b800.invoke(Ljava/lang/Object;)V java.base at 18-internal (87 bytes) @ 0x000002a03635f7b4 [0x000002a03635f4a0+0x0000000000000314]
J 620 c1 java.lang.invoke.LambdaForm$MH+0x0000000801018c00.invoke(Ljava/lang/Object;)V java.base at 18-internal (37 bytes) @ 0x000002a036353e0c [0x000002a036353720+0x00000000000006ec]
So I think the 'native code' is something being called by the safepoint blob, but I'm not sure why it's marked with a `C` instead of `V` in the stack trace (maybe just a stack unwind failure?).
FWIW, this part has already been fixed as part of: https://github.com/openjdk/jdk17/pull/173 (not sure why it still shows up in the diff)
More information about the hotspot-gc-dev