JDK-4933250 : VM asserts at mutexLocker.cpp:99
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2003-10-06
  • Updated: 2004-05-10
  • Resolved: 2003-11-19
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
5.0 b29Fixed
Related Reports
Relates :  
JDK-4926272 - methodOopDesc::method_from_bcp is unsafe
Description
VM asserts while running swingmark on solx86 and appserver on solsparc

java -version

/net/malloc/export/NEWAPPS/workload/benchmarks/swingmark( 26 )% /net/malloc.sfbay/export/VMs/latest-JDK/solx86/bin/java -server -version
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b22)
Java HotSpot(TM) Server VM (build 20031002090611.robertg.baseline-debug, mixed mode)
How to reproduce:
cd /net/malloc/export/NEWAPPS/workload/benchmarks/swingmark
/net/malloc.sfbay/export/VMs/latest-JDK/solx86/bin/java -server -DIAMHANGING -XX:CompileThreshold=100 -Xms256m -Xmx256m -XX:CompileThreshold=100 -XX:MarkSweepAlwaysCompactCount=1 -XX:NmethodSweepFraction=1 -XX:+PerfDataSaveToFile SwingMark -r 1 -q

---------------------Solx86--------------------------
/net/malloc.sfbay/export/VMs/latest-JDK/solx86/bin/java -server -DIAMHANGING -XX:CompileThreshold=1
00 -Xms256m -Xmx256m -XX:CompileThreshold=100 -XX:MarkSweepAlwaysCompactCount=1 -XX:NmethodSweepFra
ction=1 -XX:+PerfDataSaveToFile SwingMark -r 1 -q
Starting SwingMark
SwingMark Test started at Sun Oct 05 03:31:42 PDT 2003
Will run test 1 times in the same VM
Program will automatically terminate after last run
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/mutexLocker.cpp:99]
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  Internal Error (/net/prt-solx86-q1-2/PrtBuildDir/workspace/src/share/vm/runtime/mutexLocker.cpp,
 99), pid=17563, tid=9
#
# Java VM: Java HotSpot(TM) Server VM (20031002090611.robertg.baseline-debug mixed mode)
#
# Error: must own lock Compile_lock
# An error report file with more information is saved as hs_err_pid17563.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/cgi-bin/bugreport.cgi
#
VM option 'CompileThreshold=100'
VM option 'CompileThreshold=100'
VM option 'MarkSweepAlwaysCompactCount=1'
VM option 'NmethodSweepFraction=1'
VM option '+PerfDataSaveToFile'
Current thread is 9
Dumping core ...
Abort - core dumped
------------------------------------------------------
--------------------Solsparc--------------------------
[04/Oct/2003:19:51:11] INFO ( 3059): CORE1116: Sun ONE Application Server 7.0.0_01
[04/Oct/2003:19:51:12] WARNING ( 3060): CORE3283: stderr: VM option '+DisableExplicitGC'
[04/Oct/2003:19:51:12] WARNING ( 3060): CORE3283: stderr: VM option 'CompileThreshold=100'
[04/Oct/2003:19:51:12] WARNING ( 3060): CORE3283: stderr: VM option '+UseParallelGC'
[04/Oct/2003:19:51:12] WARNING ( 3060): CORE3283: stderr: VM option '+PrintGC'
[04/Oct/2003:19:51:36] INFO ( 3060): CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0-bet
a] from [Sun Microsystems Inc.]
[04/Oct/2003:19:52:16] INFO ( 3060): JMS5023: JMS service successfully started. Instance Name = dom
ain1_spec2001-1, Home = [/export/appservers/sunone/imq/bin].
[04/Oct/2003:19:52:20] INFO ( 3060): CORE3282: stdout: # To suppress the following error report, sp
ecify this argument
[04/Oct/2003:19:52:20] INFO ( 3060): CORE3282: stdout: # after -XX: or in .hotspotrc:  SuppressErro
rAt=/mutexLocker.cpp:99]
[04/Oct/2003:19:52:20] INFO ( 3060): CORE3282: stdout: #
[04/Oct/2003:19:52:20] INFO ( 3060): CORE3282: stdout: # An unexpected error has been detected by H
otSpot Virtual Machine:
[04/Oct/2003:19:52:20] INFO ( 3060): CORE3282: stdout: #
[04/Oct/2003:19:52:20] INFO ( 3060): CORE3282: stdout: #  Internal Error (/net/prt-solsparc-q1-1/tm
p/PrtBuildDir/workspace/src/share/vm/runtime/mutexLocker.cpp, 99 [ Patched ]), pid=3060, tid=35
[04/Oct/2003:19:52:20] INFO ( 3060): CORE3282: stdout: #
[04/Oct/2003:19:52:20] INFO ( 3060): CORE3282: stdout: # Java VM: Java HotSpot(TM) Server VM (20031
002090611.robertg.baseline-debug mixed mode)
[04/Oct/2003:19:52:20] INFO ( 3060): CORE3282: stdout: #
[04/Oct/2003:19:52:20] INFO ( 3060): CORE3282: stdout: # Error: must own lock Compile_lock
[04/Oct/2003:19:52:20] INFO ( 3060): CORE3282: stdout: # An error report file with more information
 is saved as hs_err_pid3060.log
[04/Oct/2003:19:52:20] INFO ( 3060): CORE3282: stdout: #
[04/Oct/2003:19:52:20] INFO ( 3060): CORE3282: stdout: # If you would like to submit a bug report,
please visit:
[04/Oct/2003:19:52:20] INFO ( 3060): CORE3282: stdout: #   http://java.sun.com/cgi-bin/bugreport.cg
i

------------------------------------------------------ 

There are a bunch of NSK tests that have this bug when run with -Xcomp.
I haven't run in that mode for a while so I don't have the list.  I thought
they were reported under a different bug though, but the string
"must own lock Compile_lock" is only found in this bug.

The nsk test:
nsk/stress/thread/thread003

got it yesterday with -d64 fastdebug intermittently with -Xshared.  Trying to
find a set of options to make it fail more frequently.

###@###.### 2003-10-29

I attached the hs_err* file.  The stack trace looks like it's coming from the
compiler:

V  [libjvm.so+0xa8dff4] void assert_locked_or_safepoint(const Mutex*)+0xd4
V  [libjvm.so+0x4396d0] int ciEnv::system_dictionary_modification_counter_change
d()+0x38
V  [libjvm.so+0x3f04b4] JVMState*ParseGenerator::generate(JVMState*)+0x2dc
V  [libjvm.so+0x58a1d4] void Parse::do_call()+0x90c
V  [libjvm.so+0xb15fb4] void Parse::do_one_block()+0x404
V  [libjvm.so+0xb0f504] void Parse::do_all_blocks()+0x16c
V  [libjvm.so+0xb0f274] Parse::Parse(JVMState*,ciMethod*,float)+0x134c
V  [libjvm.so+0x3f041c] JVMState*ParseGenerator::generate(JVMState*)+0x244
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta FIXED IN: tiger-beta INTEGRATED IN: tiger-b29 tiger-beta VERIFIED IN: tiger-beta2
14-06-2004
SUGGESTED FIX As described in comments, but use the following idiom for locking: MutexLockerEx ml(Compile_lock, Mutex::_no_safepoint_check_flag); The compiler threads are currently Java threads, and are marked as thread_in_native so they won't need to be stopped immediately at safepoints. As a result, a plain lock can fail the following assert in Mutex::check_prelock_state: # Error: assert((!thread->is_Java_thread() || ((JavaThread *)thread)->thread_sta te() == _thread_in_vm) || rank() == Mutex::special,"wrong thread state for using locks") ###@###.### 2003-11-11
11-11-2003
EVALUATION Here's the stack trace: [1] _libc_read(0xdec752f6, 0xded6ce68, 0xa), at 0xdfada590 [2] read(0xdec752f6, 0xded6ce68), at 0xdfb87998 =>[3] VMError::show_message_box(this = ???, buf = ???, buflen = ???) (optimized), at 0xde404e34 (line ~93) in "vmError_solaris.cpp" [4] VMError::report_and_die(this = ???) (optimized), at 0xde404950 (line ~538) in "vmError.cpp" [5] report_fatal(file_name = ???, line_no = ???, message = ???) (optimized), at 0xddeafd0f (line ~216) in "debug.cpp" [6] report_fatal_vararg(file_name = ???, line_no = ???, format = ???, ...) (optimized), at 0xddeafd50 (line ~225) in "debug.cpp" [7] assert_locked_or_safepoint(lock = ???) (optimized), at 0xde26d718 (line ~99) in "mutexLocker.cpp" [8] ciEnv::system_dictionary_modification_counter_changed(this = ???) (optimized), at 0xddde582d (line ~663) in "ciEnv.cpp" [9] ParseGenerator::generate(this = ???, jvms = ???) (optimized), at 0xdddafce0 (line ~61) in "callGenerator.cpp" [10] Parse::do_call(this = ???) (optimized), at 0xddeead07 (line ~317) in "doCall.cpp" [11] Parse::do_one_bytecode(this = ???) (optimized), at 0xde2ce551 (line ~1868) in "parse2.cpp" [12] Parse::do_one_block(this = ???) (optimized), at 0xde2c038f (line ~1326) in "parse1.cpp" [13] Parse::visit_blocks(this = ???) (optimized), at 0xde2bb744 (line ~609) in "parse1.cpp" [14] Parse::do_all_blocks(this = ???) (optimized), at 0xde2bb4b6 (line ~526) in "parse1.cpp" [15] Parse::Parse(this = ???, caller = ???, parse_method = ???, expected_uses = ???) (optimized), at 0xde2baf23 (line ~497) in "parse1.cpp" [16] ParseGenerator::generate(this = ???, jvms = ???) (optimized), at 0xdddafc7a (line ~58) in "callGenerator.cpp" [17] Compile::Compile(0xdd990534, 0xdd990918, 0x81b3b48, 0x9b47840, 0xffffffff, 0x1), at 0xdde63f9c [18] C2Compiler::compile_method(this = ???, env = ???, target = ???, entry_bci = ???) (optimized), at 0xdddaef94 (line ~31) in "c2compiler.cpp" [19] CompileBroker::invoke_compiler_on_method(task = ???) (optimized), at 0xdde7274b (line ~1561) in "compileBroker.cpp" [20] CompileBroker::compiler_thread_loop() (optimized), at 0xdde719ec (line ~1409) in "compileBroker.cpp" [21] compiler_thread_entry(thread = ???, __the_thread__ = ???) (optimized), at 0xde3ab847 (line ~2442) in "thread.cpp" [22] JavaThread::thread_main_inner(this = ???) (optimized), at 0xde3a6291 (line ~1233) in "thread.cpp" [23] JavaThread::run(this = ???) (optimized), at 0xde3a6112 (line ~1217) in "thread.cpp" [24] _start(0x81ee328, 0xde29de00), at 0xde29deda -------------------------------------------------- Clients of SystemDictionary::number_of_modifications should be taking out the Compiler_lock. This is a testing inhibitor and needs to be fixed for Tiger. ###@###.### 2003-10-29 ---------------------------------------------------
29-10-2003