[jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

[Jorn Vernee]

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)]

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)
C  0x000002a035d8caa7

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~SafepointBlob
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]
v  ~BufferBlob::mэYссссЫGў


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)

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

PR: https://git.openjdk.java.net/jdk17/pull/149