JDK-8156651 : SIGSEGV in StackValue::create_stack_value
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-05-10
  • Updated: 2016-10-12
  • Resolved: 2016-05-10
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
9Fixed
Related Reports
Relates :  
JDK-8147039 - Incorrect locals and operands in compiled frames
Description
#  SIGSEGV (0xb) at pc=0x00007fde7151aae0, pid=17452, tid=17480
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-05-09-214627.vkozlov.8154826)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-05-09-214627.vkozlov.8154826, compiled mode, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x135bae0]  StackValue::create_stack_value(frame const*, RegisterMap const*, ScopeValue*)+0x3f0


Current thread (0x00007fde6833a000):  JavaThread "MainThread" [_thread_in_vm, id=17480, stack(0x00007fde3d2cf000,0x00007fde3d3d0000)]

Stack: [0x00007fde3d2cf000,0x00007fde3d3d0000],  sp=0x00007fde3d3cacf0,  free space=1007k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x135bae0]  StackValue::create_stack_value(frame const*, RegisterMap const*, ScopeValue*)+0x3f0
V  [libjvm.so+0x14aba9d]  compiledVFrame::locals() const+0x29d
V  [libjvm.so+0x135e539]  StackWalk::fill_live_stackframe(Handle, methodHandle const&, int, javaVFrame*, Thread*)+0x39
V  [libjvm.so+0x135f7d1]  StackWalk::fill_in_frames(long, vframeStream&, int, int, objArrayHandle, int&, Thread*)+0x911
V  [libjvm.so+0x1363abf]  StackWalk::moreFrames(Handle, long, long, int, int, objArrayHandle, Thread*)+0x27f
V  [libjvm.so+0xdd5c3e]  JVM_MoreStackWalk+0x22e
J 4951 java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames(JJII[Ljava/lang/Object;)I java.base@9-internal (0 bytes) @ 0x00007fde6cd050d4 [0x00007fde6cd04f80+0x0000000000000154]
J 4949 C2 java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames(I)I java.base@9-internal (121 bytes) @ 0x00007fde6cd0e504 [0x00007fde6cd0e400+0x0000000000000104]
J 4948 C2 java.lang.StackStreamFactory$AbstractStackWalker.getNextBatch()I java.base@9-internal (65 bytes) @ 0x00007fde6cd0de50 [0x00007fde6cd0dde0+0x0000000000000070]
J 4937 C2 java.lang.StackStreamFactory$AbstractStackWalker.peekFrame()Ljava/lang/Class; java.base@9-internal (132 bytes) @ 0x00007fde6cd0af38 [0x00007fde6cd0ace0+0x0000000000000258]
J 4936 C2 java.lang.StackStreamFactory$StackFrameTraverser.nextStackFrame()Ljava/lang/StackWalker$StackFrame; java.base@9-internal (32 bytes) @ 0x00007fde6cd08114 [0x00007fde6cd080e0+0x0000000000000034]
j  java.lang.StackStreamFactory$StackFrameTraverser.forEachRemaining(Ljava/util/function/Consumer;)V+18 java.base@9-internal
J 3926 C2 java.util.stream.AbstractPipeline.copyInto(Ljava/util/stream/Sink;Ljava/util/Spliterator;)V java.base@9-internal (54 bytes) @ 0x00007fde6cb160fc [0x00007fde6cb16060+0x000000000000009c]
J 3921 C2 java.util.stream.AbstractPipeline.wrapAndCopyInto(Ljava/util/stream/Sink;Ljava/util/Spliterator;)Ljava/util/stream/Sink; java.base@9-internal (18 bytes) @ 0x00007fde6cb17f0c [0x00007fde6cb17e80+0x000000000000008c]
J 4303 C2 java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Ljava/util/stream/PipelineHelper;Ljava/util/Spliterator;)Ljava/lang/Object; java.base@9-internal (18 bytes) @ 0x00007fde6cbe0040 [0x00007fde6cbdffe0+0x0000000000000060]
J 3911 C2 java.util.stream.AbstractPipeline.evaluate(Ljava/util/stream/TerminalOp;)Ljava/lang/Object; java.base@9-internal (94 bytes) @ 0x00007fde6cb11c90 [0x00007fde6cb11b80+0x0000000000000110]
J 4184 C2 java.util.stream.ReferencePipeline.collect(Ljava/util/stream/Collector;)Ljava/lang/Object; java.base@9-internal (124 bytes) @ 0x00007fde6cb914bc [0x00007fde6cb91380+0x000000000000013c]
j  LocalsAndOperands$Tester.lambda$testLocals$1(Ljava/util/stream/Stream;)Ljava/util/List;+14
J 4921 C2 LocalsAndOperands$Tester$$Lambda$22.apply(Ljava/lang/Object;)Ljava/lang/Object; (8 bytes) @ 0x00007fde6cd054bc [0x00007fde6cd05460+0x000000000000005c]
J 4920 C2 java.lang.StackStreamFactory$StackFrameTraverser.consumeFrames()Ljava/lang/Object; java.base@9-internal (39 bytes) @ 0x00007fde6cd010f8 [0x00007fde6cd01000+0x00000000000000f8]
J 4914 C2 java.lang.StackStreamFactory$AbstractStackWalker.doStackWalk(JIIII)Ljava/lang/Object; java.base@9-internal (82 bytes) @ 0x00007fde6ccfe414 [0x00007fde6ccfe380+0x0000000000000094]
Comments
Verified via JDK-8147039
12-10-2016
Will be fixed by a pull from jdk9/hs.
10-05-2016
JDK-8147039 consisted of both a jdk9/hs/jdk changeset and a jdk9/hs/hotspot changeset. On the first attempt, the jdk push went through but the hotspot push did not (it failed jcheck). I saw these same crashes in jdk9/hs when that happened. The hotspot changeset was pushed later and the problem resolved. These are the changesets for the two pushes: URL: http://hg.openjdk.java.net/jdk9/hs/jdk/rev/d2f46fdfc3ca User: bchristi Date: 2016-05-06 01:14:31 +0000 URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/6174ad93770c User: bchristi Date: 2016-05-07 06:52:00 +0000 So there was a about a 30 hour window where jdk9/hs was broken. It looks like hs-comp must have pulled down during that time, because I don't see the jdk9/hs/hotspot changeset in hs-comp, but I do see the jdk9/hs/jdk changeset.
10-05-2016