JDK-8156538 : Metaspace stress test crashes VM with stack overflow
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows
  • CPU: x86_64
  • Submitted: 2016-05-09
  • Updated: 2023-07-21
  • Resolved: 2023-07-21
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.
JDK 9
9Resolved
Related Reports
Duplicate :  
JDK-8067946 - StackYellowPages and StackRedPages have no effect on Windows
Relates :  
JDK-4326445 - NSK regression test b4254544 causes Internal Error
Description
EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x0000007d300e2820, pid=34560, tid=26140

 J 64 C1 java.util.HashMap$HashIterator.<init>(Ljava/util/HashMap;)V java.base@9-internal (79 bytes) @ 0x0000007d300e2820 [0x0000007d300e2800+0x0000000000000020]
#
Comments
Crashing at 0x0000007d300e2820 when stackbanging -0x8000. This hits red zone at 0x0000007d27350fa8. The frame above also stackbangs -0x8000, then decreases rsp with 0x58 (push rbp + sub rsp 0x50) . The stackbang must have hit 0x7D27351000 which is in the yellow zone. Yellow zone obviously didn't trigger. Conclusion: Duplicate of https://bugs.openjdk.java.net/browse/JDK-8067946
16-05-2016
I meant where did the RBT build come from? Is it a clean build of jdk9/hs or is it someone's modified build? The fact the it ran in RBT doesn't really say anything about the origin of the build. The jprt bundle has been removed which I believe indicates that this was not a push job. For all we know the RBT job could be a test run of a change that was later pushed and caused this problem...
12-05-2016
Found an 0x8000 (32k) stack bang in the dump, (patched over in the first dump). That puts us directly in the red zone.
12-05-2016
Could this be the same Windows issue as JDK-8137035?
11-05-2016
I don't think this is a blocker: It has happened before in a RBT build, it has been seen exactly once in nigthlies, it doesn't reproduce, and there are no indication of any recent change related to the code in the dump.
11-05-2016
This test hit the red zone - "An unrecoverable stack overflow has occurred." in log file. It is just 58 bytes past the yellow zone. Still missing link between crash context with SP at 0x7d27358fa8 and SOE in redzone with SP at 0x7d27350fa8. Closing this as CNR if I can't find anything more.
11-05-2016
The occurrence from April 9 does not seem to be using an official build. Do we know where that build came from? If it can be proven that this bug existed in jdk9/hs before April 25 it is not a blocker (since we pushed the April 25 snapshot to jdk9/dev).
10-05-2016
No immediate luck reproducing this on sc14ia04 (64 on win64, same bundle).
10-05-2016
This got a stack overflow in compiled code. We haven't touched stack overflow in a while, and this just started happening. Giving to compiler group for initial evaluation.
09-05-2016
The hs_err log shows no GC events > GC Heap History (0 events): > No events so I don't think this is a GC issue.
09-05-2016