JDK-7092712 : JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs21,hs22
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-09-20
  • Updated: 2012-04-13
  • Resolved: 2012-04-13
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 JDK 8 Other
7u4 b01Fixed 8Fixed hs23Fixed
Related Reports
Relates :  
Relates :  
Description
A posting on mlvm-dev:

http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-September/003912.html

reports a VM crash that looks like:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xfe563edc, pid=29748, tid=20
#
# JRE version: 7.0-b147
# Java VM: Java HotSpot(TM) Server VM (21.0-b17 mixed mode solaris-x86 )
# Problematic frame:
# V  [libjvm.so+0x563edc]  bool ciKlass::is_subtype_of(ciKlass*)+0xe0
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/ct232829/hsx/hotspot-comp/7055941/crash/hs_err_pid29748.log
[thread 21 also had an error]
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

Running with a debug VM results in:

==============================================================================
Unexpected Error
------------------------------------------------------------------------------
Internal Error at ciKlass.cpp:69, pid=29921, tid=21
assert(is_loaded() && that->is_loaded()) failed: must be loaded

Do you want to debug the problem?

To debug, run 'dbx - 29921'; then switch to thread 21
Enter 'yes' to launch dbx automatically (PATH must include dbx)
Otherwise, press RETURN to abort...
==============================================================================

(dbx) where
current thread: t@21
  [1] _waitid(0x0, 0x74e2, 0xb578e780, 0x3), at 0xfeecaf95 
  [2] _waitpid(0x74e2, 0xb578e844, 0x0), at 0xfee793bf 
  [3] waitpid(0x74e2, 0xb578e844, 0x0), at 0xfeebc805 
=>[4] os::fork_and_exec(cmd = 0xfed2578c "dbx - 29921"), line 6277 in "os_solaris.cpp"
  [5] VMError::show_message_box(this = 0xb578eae4, buf = 0xfed2578c "dbx - 29921", buflen = 2000), line 56 in "vmError_solaris.cpp"
  [6] VMError::report_and_die(this = 0xb578eae4), line 806 in "vmError.cpp"
  [7] report_vm_error(file = 0xfe77a65c "/home/ct232829/hsx/hotspot-comp/hotspot/src/share/vm/ci/ciKlass.cpp", line = 69, error_msg = 0xfe77a6a0 "assert(is_loaded() && that->is_loaded()) failed", detail_msg = 0xfe77a6d0 "must be loaded"), line 216 in "debug.cpp"
  [8] ciKlass::is_subtype_of(this = 0x8480c40, that = 0x8481178), line 69 in "ciKlass.cpp"
  [9] Parse::optimize_inlining(this = 0xb578f464, caller = 0x8483a30, bci = 1, klass = 0x8481178, dest_method = 0x8484098, receiver_type = 0x842503c), line 868 in "doCall.cpp"
  [10] Parse::do_call(this = 0xb578f464), line 419 in "doCall.cpp"
  [11] Parse::do_one_bytecode(this = 0xb578f464), line 2220 in "parse2.cpp"
  [12] Parse::do_one_block(this = 0xb578f464), line 1405 in "parse1.cpp"
  [13] Parse::do_all_blocks(this = 0xb578f464), line 680 in "parse1.cpp"
  [14] Parse::Parse(this = 0xb578f464, caller = 0x80c5298, parse_method = 0x8483a30, expected_uses = 6701.0), line 589 in "parse1.cpp"
  [15] ParseGenerator::generate(this = 0x83e8a80, jvms = 0x80c5298), line 85 in "callGenerator.cpp"
  [16] Parse::do_call(this = 0xb578fd9c), line 469 in "doCall.cpp"
  [17] Parse::do_one_bytecode(this = 0xb578fd9c), line 2220 in "parse2.cpp"
  [18] Parse::do_one_block(this = 0xb578fd9c), line 1405 in "parse1.cpp"
  [19] Parse::do_all_blocks(this = 0xb578fd9c), line 680 in "parse1.cpp"
  [20] Parse::Parse(this = 0xb578fd9c, caller = 0x8411280, parse_method = 0x847fa00, expected_uses = 10000.0), line 589 in "parse1.cpp"
  [21] ParseGenerator::generate(this = 0x83e85c0, jvms = 0x8411280), line 85 in "callGenerator.cpp"
  [22] Compile::Compile(this = 0xb5790540, ci_env = 0xb5790b50, compiler = 0x830f370, target = 0x847fa00, osr_bci = -1, subsume_loads = true, do_escape_analysis = true), line 685 in "compile.cpp"
  [23] C2Compiler::compile_method(this = 0x830f370, env = 0xb5790b50, target = 0x847fa00, entry_bci = -1), line 130 in "c2compiler.cpp"
  [24] CompileBroker::invoke_compiler_on_method(task = 0x8443080), line 1680 in "compileBroker.cpp"
  [25] CompileBroker::compiler_thread_loop(), line 1521 in "compileBroker.cpp"
  [26] compiler_thread_entry(thread = 0x8320800, __the_thread__ = 0x8320800), line 2971 in "thread.cpp"
  [27] JavaThread::thread_main_inner(this = 0x8320800), line 1503 in "thread.cpp"
  [28] JavaThread::run(this = 0x8320800), line 1487 in "thread.cpp"
  [29] java_start(thread_addr = 0x8320800), line 1067 in "os_solaris.cpp"
  [30] _thr_setup(0xfd749a00), at 0xfeec71d0 
  [31] _lwp_start(0x0, 0x74e2, 0xb578e780, 0x3, 0xfd749a00, 0xfef3e000), at 0xfeec74c0 
(dbx) fr 8
Current function is ciKlass::is_subtype_of
   69     assert(is_loaded() && that->is_loaded(), "must be loaded");
(dbx) p this->print()
<ciInstanceKlass name=NEW2 loader=0xe5e88000 loaded=true initialized=true finalized=false subklass=false size=16 flags=public,super super=java/lang/Object ident=714 PERM address=0x8480c40>this->print() = (void)
(dbx) p that->print() 
<ciInstanceKlass name=NEW2 loader=0x0 loaded=false ident=720  address=0x8481178>that->print() = (void)
(dbx) 

This is another incarnation of problems with method handle signatures and boot class path (like 6939196 or 7056328).

Comments
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5eb9169b1a14
13-10-2011

EVALUATION Looking at the problem in the debugger shows that ciEnv::get_fake_invokedynamic_method_impl calls get_unloaded_method with java.lang.invoke.MethodHandle as the holder for unresolved call sites. Since the loader of j.l.i.MethodHandle is the boot class loader the resolving of e.g. signature classes is done with the boot class loader resulting in problems like: (dbx) p this->print() <ciInstanceKlass name=NEW2 loader=0xe5e88000 loaded=true initialized=true finalized=false subklass=false size=16 flags=public,super super=java/lang/Object ident=714 PERM address=0x8480c40>this->print() = (void) (dbx) p that->print() <ciInstanceKlass name=NEW2 loader=0x0 loaded=false ident=720 address=0x8481178>that->print() = (void) later in the game. A ciInstanceKlass lookup for NEW2 returns a ciInstanceKlass created during the signature resolving in get_unloaded_method with the boot class loader as loader resulting in the above situation.
20-09-2011