JDK-8224684 : vmTestbase/nsk/stress/stack/stack002.java Undersized StackShadowPages
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 13
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: windows
  • CPU: x86_64
  • Submitted: 2019-05-23
  • Updated: 2020-08-19
  • Resolved: 2020-07-14
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
tbdResolved
Related Reports
Relates :  
Description
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=src/hotspot/os/windows/os_windows.cpp:2493
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (src/hotspot/os/windows/os_windows.cpp:2493), pid=45312, tid=43884
#  assert(thread->thread_state() != _thread_in_vm) failed: Undersized StackShadowPages
#
# JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug build 13-ea+0-1074)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-ea+0-1074, compiled mode, sharing, compressed oops, g1 gc, windows-amd64)
# Core dump will be written. Default location: hs_err_pid45312.mdmp
#
# An error report file with more information is saved as:
# hs_err_pid45312.log
Comments
ILW = HLL = P4 (WA: increase stack shadow pages value)
04-06-2019

Looks like JDK-8179540 which was closed as "Cannot Reproduce". Moving to hotspot/runtime.
29-05-2019

hs_err is truncated, only containing: --------------- T H R E A D --------------- Current thread (0x000000564e564000): JavaThread "Thread-1" [_thread_in_vm, id=43884, stack(0x000000564fe70000,0x000000564ff70000)] Stack: [0x000000564fe70000,0x000000564ff70000] And dump is 0 bytes. The old issue, 8179540, do not have any data left. If I understand the circumstances correct: we are very near the stack bound and then while doing a stack allocation in vm we jump over yellow and red ? So here: frame fr = _context ? os::fetch_frame_from_context(_context) : os::current_frame(); The _context pc points outside the stack, therefore err reporting do not work? If so we must decrease it and do best effort generating a stack-trace, e.g. guessing a bit where the below frame is based on addresses found on stack. I'll try to reproduce and just call abort directly and see if we can get a minidump. I did 500 runs, I got nothing. Someone with a spare windows machine should loop it, if there is no better idea. (fixing error reporting handling unusable pc is not trivial)
29-05-2019