JDK-8279663 : serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java fails on Windows in loom repo
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: repo-loom
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-01-10
  • Updated: 2022-07-08
  • Resolved: 2022-04-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
repo-loomFixed
Related Reports
Relates :  
JDK-8290013 - serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java failed "assert(!in_vm) failed: Undersized StackShadowPages"
Description
loom repo, Windows only, higher tier that runs the test with -Xbatch -Xcomp, -XX:-TieredCompilation, -XX:CompileThreshold=100.

The test seems to get a stack overflow, typical output is:

----------System.out:(25/1585)*----------
AGENT: Agent_OnLoad started.
AGENT: Agent_Initialize started
AGENT: Agent_Initialize finished
AGENT: VM init event
AGENT: Start new thread that performs GetLocalObject calls on a running target thread
### Java-Test: Set target thread for get local variable calls by agent.
### Java-Test: Test how many frames fit on the stack by performing recursive calls until
### Java-Test: StackOverflowError is thrown
### Java-Test: Testing with target depth: 20664
### Java-Test: Begin Test.
### Java-Test: 0 ms  Iteration : 0  waitTime : 1
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=\\os_windows.cpp:2610
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (t:\\workspace\\open\\src\\hotspot\\os\\windows\\os_windows.cpp:2610), pid=27220, tid=52708
#  assert(!in_vm) failed: Undersized StackShadowPages
#
# JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal+0-2022-01-09-1508384.alan.bateman.loom)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal+0-2022-01-09-1508384.alan.bateman.loom, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Core dump will be written. Default location: T:\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_hotspot_serviceability\\scratch\\4\\hs_err_pid27220.mdmp
#
# An error report file with more information is saved as:
# T:\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_hotspot_serviceability\\scratch\\4\\hs_err_pid27220.log
----------System.err:(0/0)----------
Comments
RegisterMap in loom is 4752 bytes vs. 4736 in jdk/jdk, which isn't a big change. On linux, printing stack pointers in javaCalls::call_helper and the callee fill_in_stack_trace for the StackOverflowCall here: (gdb) print 0x00007f910b90d030-0x00007f910b90a900 $1 = 10032 <= stack usage in mainline (gdb) print 0x00007f1d117c7fd0-0x00007f1d117c5850 $2 = 10112 <= stack usage in loom (gdb) print 10112-10032 $3 = 80 <= difference in bytes On Windows, same test: (gdb) print 0x2944309ba0-0x2944307350 $4 = 10320 <= stack usage in mainline (gdb) print 0xaa44209b00-0xaa44207200 $5 = 10496 <= stack usage in loom (gdb) print 10496-10320 $6 = 176 <= difference So windows uses a bit more stack along the path that got the native stack overflow (thread_in_java). With the smaller StackShadowPages default, this is enough to cause the native stack overflow, and the error message in the assert suggesting increasing StackShadowPage default is the right fix.
28-04-2022
Correction: there doesn't seem to be a *new* RegisterMap in the loom code, but the RegisterMap is a few words larger. Adding this to fill_in_stack_trace() in mainline, also makes it fail with the same crash: log_info(os)("in fill_in_stack_trace sp " INTPTR_FORMAT, p2i(os::current_stack_pointer()));
28-04-2022
It looks like the Windows StackShadowPages is 7 DEBUG_ONLY(+2) which is a lot smaller than Linux. This is fine until we added a RegisterMap in the loom code in fill_in_stack_trace. #ifdef ASSERT vframeStream st(thread, false /* stop_at_java_call_stub */, false /* process_frames */); #endif int total_count = 0; RegisterMap map(thread, false /* update */, false /* process_frames */, true /* walk_cont */); int decode_offset = 0; This code creates a RegisterMap on the ASSERT path in the vframeStream constructor, and another one. Trying to make the windows StackShadowPages 7 DEBUG_ONLY(+4) to see if that causes this to pass.
27-04-2022
It fails in the fibers branch without the wrapper. Thanks to [~erikj] I have a stack: V [jvm.dll+0x57fb67] report_vm_error+0xb7 (debug.cpp:283) V [jvm.dll+0xc43ba6] topLevelExceptionFilter+0x1d6 (os_windows.cpp:2606) <== this is there the assert(!in_vm) is. V [jvm.dll+0xf37657] JNI_CreateJavaVM$filt$0+0x17 (jni.cpp:3720) C [VCRUNTIME140.dll+0xef90] C [ntdll.dll+0xa20cf] C [ntdll.dll+0x51454] C [ntdll.dll+0xa0bfe] V [jvm.dll+0xf36ef7] __chkstk+0x37 (chkstk.asm:109) V [jvm.dll+0x403612] vframeStream::vframeStream+0x32 (vframe.inline.hpp:111) V [jvm.dll+0x7d61f2] java_lang_Throwable::fill_in_stack_trace+0x292 (javaClasses.cpp:2790) V [jvm.dll+0x7d5f36] java_lang_Throwable::fill_in_stack_trace+0x86 (javaClasses.cpp:2925) V [jvm.dll+0x63aa08] Exceptions::throw_stack_overflow_exception+0x138 (exceptions.cpp:245) V [jvm.dll+0x7c6b0e] JavaCalls::call_helper+0x35e (javaCalls.cpp:388) V [jvm.dll+0xc44fac] os::os_exception_wrapper+0x2c (os_windows_x86.cpp:113) V [jvm.dll+0x7c769b] JavaCalls::call_static+0x11b (javaCalls.cpp:258) V [jvm.dll+0x7c78f3] JavaCalls::call_static+0xa3 (javaCalls.cpp:278) V [jvm.dll+0xbf21db] NativeLookup::lookup_style+0x38b (nativeLookup.cpp:285) V [jvm.dll+0xbf199d] NativeLookup::lookup_entry+0x1dd (nativeLookup.cpp:335) V [jvm.dll+0xbf1533] NativeLookup::lookup+0x93 (nativeLookup.cpp:440) V [jvm.dll+0x5254af] CompileBroker::compile_method+0x41f (compileBroker.cpp:1420) V [jvm.dll+0x5257a1] CompileBroker::compile_method+0xd1 (compileBroker.cpp:1353) V [jvm.dll+0x50b7cf] CompilationPolicy::compile_if_required+0x26f (compilationPolicy.cpp:110) V [jvm.dll+0xa6d922] LinkResolver::resolve_static_call+0x1c2 (linkResolver.cpp:1094) V [jvm.dll+0xa6c881] LinkResolver::resolve_invoke+0xc1 (linkResolver.cpp:1626) V [jvm.dll+0xd053b4] SharedRuntime::find_callee_info_helper+0x6a4 (sharedRuntime.cpp:1184) V [jvm.dll+0xd0c0b2] SharedRuntime::resolve_sub_helper+0x222 (sharedRuntime.cpp:1377) V [jvm.dll+0xd0b6df] SharedRuntime::resolve_helper+0x4f (sharedRuntime.cpp:1249) V [jvm.dll+0xd0bd6f] SharedRuntime::resolve_static_call_C+0x1ff (sharedRuntime.cpp:1563)
27-04-2022
This test has been on the exclude list for a long time because it failed too often. Do we know if it fails in the jep-vt branch, or in the fibers branch with -XX:-LoomVM ?
27-04-2022
Moving this issue to the Runtime team for evaluation. Please, feel free to move it back to JVM TI if necessary.
13-03-2022
Okay, then it is most likely not a JVMTI issue. Will try to check if JVMTI contributed anything to this. Unfortunately, I've not been able to reproduce this on Windows yet. Will try more.
08-02-2022
I don't think this is a test issue, this is a stack overflow generation issue with Windows. It may be related to stack banging, or it may be as the assert states that we don't have sufficient shadow space in some circumstances. You would need to check the core/hs_err file to determine exactly what the state of the stack was when the assertion fired. There may be something Loom specific affecting this.
07-02-2022
This is a test issue. The test provokes StackOverflowError to find max possible stack depth: public int recursiveMethod(int depth, int targetStackDepth) { int maxDepth = depth; try { if (depth == targetStackDepth) { notifyAgentToGetLocal(depth - 100, waitCycles); } else { maxDepth = recursiveMethod(depth + 1, targetStackDepth); } } catch (StackOverflowError e) { // Don't print message here, because this would likely trigger a new StackOverflowError } return maxDepth; } Apparently, it does not always work as expected. It can be this fails on Windows only.
07-02-2022