United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4926272 methodOopDesc::method_from_bcp is unsafe
JDK-4926272 : methodOopDesc::method_from_bcp is unsafe

Details
Type:
Bug
Submit Date:
2003-09-22
Status:
Closed
Updated Date:
2014-03-21
Project Name:
JDK
Resolved Date:
2011-03-07
Component:
hotspot
OS:
generic
Sub-Component:
runtime
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs13,hs19,5.0,7
Fixed Versions:
hs20 (b07)

Related Reports
Backport:
Backport:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
The implementation of methodOopDesc::method_from_bcp needs to be 
re-examined with to make it safe to use in all heap configurations.
This is used with the full speed debugging with C2. The current
implementation is unsafe because it uses block_start when the VM
is not at a safepoint.  The following demonstrates one such crash in 
when NSK tests are run in -server -XX:+UseConcMarkSweepGC mode :-


#!/bin/sh

LD_LIBRARY_PATH=/export/Scratch/alanb/nsk/testbase_vm.1.5/src/nsk/share/lib/intel:/export/Users/alanb/ws/service_sdk_baseline/build/solaris-i586/jre/lib/i386/client
CLASSPATH=/export/Scratch/alanb/nsk/results/solx86_server_cms_jdi/ab23780.Solaris.x86/nextevent001:/export/Scratch/alanb/nsk/testbase_vm.1.5/bin/classes:/export/Users/alanb/ws/service_sdk_baseline/build/solaris-i586/lib/tools.jar
DISPLAY=mrbean:0.0
PATH=/export/Users/alanb/ws/service_sdk_baseline/build/solaris-i586/bin:/export/Users/alanb/ws/service_sdk_baseline/build/solaris-i586/jre/bin
RAS_OPTIONS=
HOME=/home/ab23780
SHELL=/bin/sh

while [ $# -gt 0 ];
do
  if [ $1 = "-jdk" ]; then
	shift 1
	PATH=${1}/bin:${PATH}
	shift 1
  else
	if [ $1 = "-d" ]; then
	  shift 1
	  if [ $# -gt 0  ]; then
		DISPLAY=$1
		shift 1
	  else
		DISPLAY=:0.0
	  fi
	fi
  fi
done

export LD_LIBRARY_PATH
export CLASSPATH
export DISPLAY
export PATH
export RAS_OPTIONS
export HOME
export SHELL
/export/Users/alanb/ws/service_sdk_baseline/build/solaris-i586/bin/java -client nsk.jdi.EventIterator.nextEvent.nextevent001 -arch=intel -waittime=1 -debugee.vmkind=java "-debugee.vmkeys=-server -XX:+UseConcMarkSweepGC -XX:-SafepointPolling"
##Exit status of execution step=97
##Core file exists
##!checkExitCode

#debugee.stdout> # To suppress the following error report, specify this argument
#debugee.stdout> # after -XX: or in .hotspotrc:  SuppressErrorAt=/mutexLocker.cpp:100]
#debugee.stdout> #
#debugee.stdout> # An unexpected error has been detected by HotSpot Virtual Machine:
#debugee.stdout> #
#debugee.stdout> #  Internal Error (/net/jsn2/export/Users/alanb/ws/jvmti/src/share/vm/runtime/mutexLocker.cpp, 100), pid=5322, tid=22
#debugee.stdout> #
#debugee.stdout> # Java VM: Java HotSpot(TM) Server VM (1.5-internal-debug mixed mode)
#debugee.stdout> #
#debugee.stdout> # Error: must own lock Heap_lock
#debugee.stdout> # An error report file with more information is saved as hs_err_pid5322.log
#debugee.stdout> #
#debugee.stdout> # If you would like to submit a bug report, please visit:
#debugee.stdout> #   http://java.sun.com/cgi-bin/bugreport.cgi
#debugee.stdout> #
#debugee.stdout> VM option '+UseConcMarkSweepGC'
#debugee.stdout> VM option '-SafepointPolling'
#debugee.stdout> Current thread is 22
#debugee.stdout> Dumping core ...
##>  
##>  WARNING: switching log to verbose mode,
##>      because error is complained
##>  
#--> debugger: launching a debuggee :
#--> debugger:        nsk.jdi.EventIterator.nextEvent.nextevent001a
#binder> VirtualMachineManager: version 1.4
#binder> Finding connector: default
#binder> LaunchingConnector:
#binder>     name: com.sun.jdi.CommandLineLaunch
#binder>     description: Launches target using Sun Java VM command line and attaches to it
#binder>     transport: com.sun.tools.jdi.SunCommandLineLauncher$2@291aff
#binder> Connector arguments:
#binder>     home=/export/Scratch/alanb/builds/service_sdk_baseline/build/solaris-i586
#binder>     vmexec=java
#binder>     options=-server -XX:+UseConcMarkSweepGC -XX:-SafepointPolling
#binder>     main=nsk.jdi.EventIterator.nextEvent.nextevent001a -arch=intel "-waittime=1" "-debugee.vmkind=java" "-debugee.vmkeys=-server -XX:+UseConcMarkSweepGC -XX:-SafepointPolling"
#binder>     quote="
#binder>     suspend=true
#binder> Launching debugee
#binder> Redirecting VM output
er:       a MethodEntry has been set up
#--> debugger: ......setting up MethodExit:
#--> debugger:        thread: instance of nsk.jdi.EventIterator.nextEvent.nextevent001a$Thread1nextevent001a(name='mexThread', id=74); class: class nsk.jdi.EventIterator.nextEvent.TestClass (loaded by instance of sun.misc.Launcher$AppClassLoader(id=54)); property: mexThread
#--> debugger:       a MethodExit has been set up
#--> debugger: ......setting up Step:
#--> debugger:        thread: instance of nsk.jdi.EventIterator.nextEvent.nextevent001a$Thread2nextevent001a(name='stThread', id=73); property: stThread
#--> debugger:       a Step has been set up
#--> debugger: :::::::::vm.resume();
#--> debugger: ......getting and checking up on Events
#debugee.stdout> # To suppress the following error report, specify this argument
#debugee.stdout> # after -XX: or in .hotspotrc:  SuppressErrorAt=/mutexLocker.cpp:100]
#debugee.stdout> #
#debugee.stdout> # An unexpected error has been detected by HotSpot Virtual Machine:
#debugee.stdout> #
#debugee.stdout> #  Internal Error (/net/jsn2/export/Users/alanb/ws/jvmti/src/share/vm/runtime/mutexLocker.cpp, 100), pid=5322, tid=22
#debugee.stdout> #
#debugee.stdout> # Java VM: Java HotSpot(TM) Server VM (1.5-internal-debug mixed mode)
#debugee.stdout> #
#debugee.stdout> # Error: must own lock Heap_lock
#debugee.stdout> # An error report file with more information is saved as hs_err_pid5322.log
#debugee.stdout> #
#debugee.stdout> # If you would like to submit a bug report, please visit:
#debugee.stdout> #   http://java.sun.com/cgi-bin/bugreport.cgi
#debugee.stdout> #
#debugee.stdout> VM option '+UseConcMarkSweepGC'
#debugee.stdout> VM option '-SafepointPolling'
#debugee.stdout> Current thread is 22
#debugee.stdout> Dumping core ...
## ERROR: ##> debugger: ERROR: else clause in detecting type of event1
## ERROR: ##> debugger: ERROR: event duplication: null
## ERROR: ##> debugger: ERROR: Exception : nsk.jdi.EventIterator.nextEvent.nextevent001$JDITestRuntimeException: JDITestRuntimeException : ** EXCEPTION while waiting for event ** : com.sun.jdi.VMDisconnectedException
## ERROR: ##> debugger: test phase has not finished normally: debuggee is still alive
#--> debugger: ......forcing: vm.exit();
## ERROR: ##> debugger: ERROR: Exception : e
#TEST FAILED
#
#
##>  
##>  SUMMARY: Following errors occured
##>      during test execution:
##>  
## ERROR: ##> debugger: ERROR: else clause in detecting type of event1
## ERROR: ##> debugger: ERROR: event duplication: null
## ERROR: ##> debugger: ERROR: Exception : nsk.jdi.EventIterator.nextEvent.nextevent001$JDITestRuntimeException: JDITestRuntimeException : ** EXCEPTION while waiting for event ** : com.sun.jdi.VMDisconnectedException
## ERROR: ##> debugger: test phase has not finished normally: debuggee is still alive
## ERROR: ##> debugger: ERROR: Exception : e



Here's the backtrace from the core file :-


  [1] __sigprocmask(0x0, 0x18, 0xdfb99000), at 0xdfb86971 
  [2] _resetsig(), at 0xdfb7d4b5 
  [3] _sigon(), at 0xdfb7cdbe 
  [4] _lmutex_unlock(0xdfba0540), at 0xdfb7a7d0 
  [5] _thrp_kill(), at 0xdfb7f477 
  [6] _ti_thr_kill(0x18, 0x6), at 0xdfb7f368 
  [7] raise(0x6), at 0xdfaeb6ff 
  [8] abort(), at 0xdfadbb30 
  [9] os::abort(0x1), at 0xde36869d 
=>[10] VMError::report_and_die(this = ???) (optimized), at 0xde4c2482 (line ~679) in "vmError.cpp"
  [11] report_fatal(file_name = ???, line_no = ???, message = ???) (optimized), at 0xddf45d3f (line ~216) in "debug.cpp"
  [12] report_fatal_vararg(file_name = ???, line_no = ???, format = ???, ...) (optimized), at 0xddf45d80 (line ~225) in "debug.cpp"
  [13] assert_locked_or_safepoint(lock = ???) (optimized), at 0xde336868 (line ~100) in "mutexLocker.cpp"
  [14] CompactibleFreeListSpace::verify_objects_initialized(this = ???) (optimized), at 0xddef332b (line ~665) in "compactibleFreeListSpace.cpp"
  [15] CompactibleFreeListSpace::block_start(this = ???, p = ???) (optimized), at 0xddef358a (line ~741) in "compactibleFreeListSpace.cpp"
  [16] GenerationBlockStartClosure::do_space(this = ???, s = ???) (optimized), at 0xddfb810f (line ~152) in "generation.cpp"
  [17] ConcurrentMarkSweepGeneration::space_iterate(this = ???, blk = ???, usedOnly = ???) (optimized), at 0xddf19644 (line ~617) in "concurrentMarkSweepGeneration.cpp"
  [18] Generation::block_start(this = ???, p = ???) (optimized), at 0xddfb695a (line ~161) in "generation.cpp"
  [19] methodOopDesc::method_from_bcp(0xd752d792), at 0xde3242ea 
  [20] Bytecodes::non_breakpoint_code_at(bcp = ???, method = ???) (optimized), at 0xdde4bf72 (line ~30) in "bytecodes.cpp"
  [21] InterpreterRuntime::already_resolved(thread = ???) (optimized), at 0xde01a905 (line ~23) in "interpreterRuntime.hpp"
  [22] InterpreterRuntime::resolve_invoke(thread = ???, bytecode = ???) (optimized), at 0xde015636 (line ~542) in "interpreterRuntime.cpp"
  [23] 0xdb81ac15(), at 0xdb81ac14 
  [24] 0xdb80324b(), at 0xdb80324a 
  [25] 0xdb8000fa(0xd0ca0898, 0xd0ca0ac4, 0xa, 0xd753d560, 0xdb80b480, 0xd0ca09a8, 0x1, 0x8193250), at 0xdb8000f9 
  [26] JavaCalls::call_helper(result = ???, m = ???, args = ???, __the_thread__ = ???) (optimized), at 0xde02758f (line ~367) in "javaCalls.cpp"
  [27] os::os_exception_wrapper(0xde027304, 0xd0ca0ac0, 0xd0ca0938, 0xd0ca09a0, 0x8193250), at 0xde36baf5 
  [28] JavaCalls::call(result = ???, method = CLASS, args = ???, __the_thread__ = ???) (optimized), at 0xde0272ff (line ~286) in "javaCalls.cpp"
  [29] JavaCalls::call_virtual(result = ???, spec_klass = CLASS, name = CLASS, signature = CLASS, args = ???, __the_thread__ = ???) (optimized), at 0xde026a65 (line ~182) in "javaCalls.cpp"
  [30] JavaCalls::call_virtual(result = ???, receiver = CLASS, spec_klass = CLASS, name = CLASS, signature = CLASS, __the_thread__ = ???) (optimized), at 0xde026bc7 (line ~188) in "javaCalls.cpp"
  [31] thread_entry(thread = 0x8193250, __the_thread__ = 0x8193250), line 2181 in "jvm.cpp"
  [32] JavaThread::thread_main_inner(this = ???) (optimized), at 0xde467cf1 (line ~1214) in "thread.cpp"
  [33] JavaThread::run(this = ???) (optimized), at 0xde467b72 (line ~1198) in "thread.cpp"
  [34] _start(0x8193250, 0xde367150), at 0xde36722a 
(dbx)
http://vmsqe.sfbay/nightly/mantis/DTWS/results/11-26-05/ServerVM/Solsparc/mixed/Gc_Baseline-Xconc/nsk.jvmti-NIGHTLY-Gc_Baseline-Xconc-ServerVM-mixed-Solsparc-2005-11-26-22-30-49/ResultDir/clrbrk001/hs_err_pid14945.log

For the tlog file itself, replace the last component of URL with clrbrk001.log

----

#!/usr/bin/sh

CLASSPATH=/var/tmp/Work/Work/exec/nsk.jvmti-NIGHTLY-Gc_Baseline-Xconc-ServerVM-mixed-Solsparc-2005-11-26-22-30-49/run2/fhsu.Solaris.sparc/clrbrk001:/net/vmsqe.sfbay/export/backup/testbase/testbase_vm.1.6_r02/vm/bin/classes:/var/tmp/Work/Work/JDK/NIGHTLY/Gc_Baseline-Xconc/solaris-sparc/lib/tools.jar
HOME=/var/tmp
RAS_OPTIONS=
LD_LIBRARY_PATH=/net/vmsqe.sfbay/export/backup/testbase/testbase_vm.1.6_r02/vm/bin/lib/sparc/nsk/jvmti/ClearBreakpoint:/net/vmsqe.sfbay/export/backup/testbase/testbase_vm.1.6_r02/vm/src/nsk/share/lib/sparc:/var/tmp/Work/Work/JDK/NIGHTLY/Gc_Baseline-Xconc/solaris-sparc/jre/lib/sparc/server
PATH=/var/tmp/Work/Work/JDK/NIGHTLY/Gc_Baseline-Xconc/solaris-sparc/bin:/bin:/usr/bin:/var/tmp/Work/Work/JDK/NIGHTLY/Gc_Baseline-Xconc/solaris-sparc/jre/bin
DISPLAY=vmsqe.sfbay:0.0
SHELL=/usr/bin/sh

while [ $# -gt 0 ];
do
  if [ $1 = "-jdk" ]; then
	shift 1
	PATH=${1}/bin:${PATH}
	shift 1
  else
	if [ $1 = "-d" ]; then
	  shift 1
	  if [ $# -gt 0  ]; then
		DISPLAY=$1
		shift 1
	  else
		DISPLAY=:0.0
	  fi
	fi
  fi
done

export CLASSPATH
export HOME
export RAS_OPTIONS
export LD_LIBRARY_PATH
export PATH
export DISPLAY
export SHELL

#annotate TEST javaopt=/var/tmp/Work/Work/JDK/NIGHTLY/Gc_Baseline-Xconc/solaris-sparc/bin/java -server -Xmixed -XX:-PrintVMOptions -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:+ExplicitGCInvokesConcurrent -agentlib:clrbrk001
/usr/bin/perl /net/vmsqe.sfbay/export/backup/testbase/testbase_vm.1.6_r02/vm/src/nsk/share/jvmti/run_jvmti.pl /var/tmp/Work/Work/JDK/NIGHTLY/Gc_Baseline-Xconc/solaris-sparc/bin/java -server -Xmixed -DHANGINGJAVA10039 -XX:-PrintVMOptions -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:+ExplicitGCInvokesConcurrent -agentlib:clrbrk001 nsk.jvmti.ClearBreakpoint.clrbrk001
##Exit status of execution step=6
##Core file exists
##!checkExitCode

## 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 Java Runtime Environment:
##
##  Internal Error (/net/prt-solsparc-q1-19/tmp/PrtBuildDir/workspace/src/share/vm/runtime/mutexLocker.cpp, 99 [ Patched ]), pid=14945, tid=14
##
## Java VM: Java HotSpot(TM) Server VM (20051123161237.pbk.gc2main-debug mixed mode)
##
## Error: must own lock Heap_lock
## An error report file with more information is saved as hs_err_pid14945.log
##
## If you would like to submit a bug report, please visit:
##   http://java.sun.com/webapps/bugreport/crash.jsp
##
#VM option '-PrintVMOptions'
#VM option '+UseConcMarkSweepGC'
#VM option '+CMSPermGenSweepingEnabled'
#VM option '+CMSClassUnloadingEnabled'
#VM option '+ExplicitGCInvokesConcurrent'
#Current thread is 14
#Dumping core ...


-----

nsk.jvmti.ClearBreakpoint.clrbrk001

nsk/jvmti/ClearBreakpoint/clrbrk001

-----
http://sqeweb.sfbay.sun.com/nfs/tools/gtee/results/JDK7/NIGHTLY/VM/2010-07-29/GC_Baseline-Xconc/known_failures.html

nsk/jvmti/ClearBreakpoint/clrbrk001
nsk/jvmti/scenarios/hotswap/HS203/hs203t004
Here is an instance of this assertion failure from the
2010.08.30 Main_Baseline nightly:

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/mutexLocker.cpp:136
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/tmp/jprt/P1/B/170631.ap31282/source/src/share/vm/runtime/mutexLocker.cpp:136), pid=8585, tid=3072199568
#  fatal error: must own lock Heap_lock
#
# JRE version: 7.0
# Java VM: Java HotSpot(TM) Client VM (19.0-b06-201008301706.ap31282.hs-merge-fastdebug mixed mode linux-x86 )
# An error report file with more information is saved as:
# /net/sqenfs-2.sfbay/export2/results/vm/gtee/JDK7/NIGHTLY/VM/2010-08-30/Main_Baseline/javase/linux-i586/client/mixed/linux-i586_javase_client_mixed_JT_JDK_com_sun_jdi/workDir/com/sun/jdi/BreakpointTest/hs_err_pid8585.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

http://sqeweb.sfbay/nfs/tools/gtee/results/JDK7/NIGHTLY/VM/2010-08-30/Main_Baseline/javase/linux-i586/client/mixed/linux-i586_javase_client_mixed_JT_JDK_com_sun_jdi/analysis.html

The formatting of the message has changed from earlier entries.
com/sun/jdi/GetLocalVariables4Test.sh
com/sun/jdi/SimulResumerTest.java

                                    

Comments
EVALUATION

This needs to be discussed for tiger.
                                     
2004-06-11
EVALUATION

I posted a suggested fix which makes the crash go away.  I think a cleanup of making sure 'method' is passed to nonbreakpoint_code_at and getting rid of method_from_bcp is the complete fix, but I don't want to add that to the compressed oops workspace yet.

Closing the other bug as a duplicate of this one.
                                     
2008-02-21
EVALUATION

I had a go at supplying the methodOop in all callers to non_breakpoint_code_at() but hit a snag in bytecode.hpp, code_at() and length_at() are called without methodOop available (or adding it to this and all callers got pretty ugly).

Bytecodes::Code code() const                   { return Bytecodes::code_at(addr_at(0)); }
  Bytecodes::Code java_code() const              { return Bytecodes::java_code(code()); }
  bool must_rewrite() const                      { return Bytecodes::can_rewrite(code()) && check_must_rewrite(); }

Posted in suggested_fix another place java_code_at() called without available methodOop which was causing lots of aborts in tests.
                                     
2008-03-11
SUGGESTED FIX

Another place where tests fail with -Xcomp, eg:

nsk/jdi/BScenarios/hotswap/tc04x001

436,440c436,440
<   methodOop m = (methodOop)this;  // pass to code_at() to avoid method_from_bcp
<   if (Bytecodes::java_code_at(code_base()+0, m) != Bytecodes::_aload_0 ) return false;
<   if (Bytecodes::java_code_at(code_base()+1, m) != Bytecodes::_getfield) return false;
<   if (Bytecodes::java_code_at(code_base()+4, m) != Bytecodes::_areturn &&
<       Bytecodes::java_code_at(code_base()+4, m) != Bytecodes::_ireturn ) return false;
---
>   if (Bytecodes::java_code_at(code_base()+0) != Bytecodes::_aload_0 ) return false;
>   if (Bytecodes::java_code_at(code_base()+1) != Bytecodes::_getfield) return false;
>   Bytecodes::Code ret_bc = Bytecodes::java_code_at(code_base()+4);
>   if (Bytecodes::java_code_at(code_base()+4) != Bytecodes::_areturn &&
>       Bytecodes::java_code_at(code_base()+4) != Bytecodes::_ireturn ) return false;
                                     
2008-03-11
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8012aa3ccede
                                     
2011-01-14
SUGGESTED FIX

philli% diff -b interpreterRuntime.hpp $rt/src/share/vm/interpreter
2c2
< #pragma ident "@(#)interpreterRuntime.hpp     1.144 08/02/21 14:45:01 JVM"
---
> #pragma ident "@(#)interpreterRuntime.hpp     1.143 07/05/05 17:05:38 JVM"
41c41
<   static Bytecodes::Code code(JavaThread *thread)       { return Bytecodes::code_at(bcp(thread), method(thread)); }
---
>   static Bytecodes::Code code(JavaThread *thread)       { return Bytecodes::code_at(bcp(thread)); }
                                     
2008-02-21
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8012aa3ccede
                                     
2011-01-20
EVALUATION

4926272: methodOopDesc::method_from_bcp is unsafe
Reviewed-by:

To deal transparently with breakpoint bytecodes many of the bytecode
routines may need access to the original methodOop.  Currently we are
relying on GC machinery toscan backwards to the beginning of the oop.
This doesn't always work with CMS and won't exist when we remove the
perm gen.  The fix is to require passing around the methodOop.  This
required changing these Bytecodes into StackObjs which cause a few
other syntaactic changes like converting -> to . in quite a few
places.  It created a little inconsistency with some of the other
Bytecode classes that I chose to fix.  They are all now StackObj and I
got rid of the *_at helpers and moved the verify calls into the
constructors.  I also eliminated ThisRelativeObj completely and
changed a few names.  Tested with nsk jvmti related tests.

I've updated the webrev wit the following changes.  It's now always method, bcp/bci.  I removed methodOop from a few minor places where it wasn't needed.  I changed bytecode to extract the Code in the constructor and made a few changes in Bytescodes to allow this.  This would allow it work with breakpoints in the CI.  I changed Bytecode_loadconstant and Bytecode_member_ref to inherit from Bytecode and removed some redundant/unneeded fields and methods.  I added constructors that take a ciBytecodeStream* to build the CI versions of the Bytecode and placed the definitions in ciStreams.hpp so they could be inlined.  Moved the must_rewrite logic into Bytecodes with the can_rewrite stuff.  Added java_code_at and code_at to methodOop.  Renamed Bytecode_invoke_at_check to Bytecode_invoke_check.
                                     
2011-01-14



Hardware and Software, Engineered to Work Together