JDK-7009923 : JSR 292: VM crash in JavaThread::last_frame
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs20
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-01-03
  • Updated: 2012-02-01
  • Resolved: 2011-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 7 Other
7Fixed hs21Fixed
Related Reports
Relates :  
JDK-7066143 - JSR 292: Zero support after regressions from 7009923 and 7009309
Description
VM crashes with:

#  SIGSEGV (0xb) at pc=0xb6ec6ef7, pid=12007, tid=3065453424
#
# JRE version: 7.0-b123
# Java VM: Java HotSpot(TM) Server VM (20.0-b04 mixed mode linux-x86 )
# Problematic frame:
# V  [libjvm.so+0x32eef7]  JavaThread::last_frame()+0xa7

Stack: [0xb6b21000,0xb6b72000],  sp=0xb6b70e34,  free space=319k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x32eef7]  JavaThread::last_frame()+0xa7
V  [libjvm.so+0x3c8eaf]  java_lang_Throwable::fill_in_stack_trace(Handle, Thread*)+0x25f
V  [libjvm.so+0x3c95bb]  java_lang_Throwable::fill_in_stack_trace(Handle)+0x5b
V  [libjvm.so+0x3235f8]  Exceptions::throw_stack_overflow_exception(Thread*, char const*, int)+0xb8
V  [libjvm.so+0x3c129b]  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x1cb
V  [libjvm.so+0x557239]  os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x19
V  [libjvm.so+0x3c02df]  JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x2f
V  [libjvm.so+0x3cb63a]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x21a
V  [libjvm.so+0x3d1a1a]  jni_CallStaticVoidMethod+0xba
C  [libjli.so+0x25f0]  JavaMain+0x560
C  [libpthread.so.0+0x667f]  start_thread+0xbf

The class file is attached. Please run it with -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic.

Note that every method in this class has max_stack == max_locals == 65535.

The bug does not reproduce with JDK7 b121.

The crash was reported by Remi Forax in ###@###.### mailing list. See
http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-January/002268.html.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/01147d8aac1d
28-04-2011
EVALUATION Summary: Handle stack overflow before the first frame is called, by printing out the called method and not walking the stack. Reviewed-by: dholmes, phh, dsamersoff
27-04-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/01147d8aac1d
26-04-2011
EVALUATION This is not a JSR 292 bug. The error happens before user-provided bytecode is even entered. The problem is that the default stack size is too small. The crash happens because Exceptions::throw_stack_overflow_exception (called *directly* from the VM's call_helper) fails to assemble a meaningful stack backtrace. This is probably some sort of corner case, since the stack trace should be completely empty at this point. (IndyTest.main has not yet been entered; it is IndyTest.main that has a silly locals count of 0xFFFF.)
30-03-2011