Bug ID: JDK-4926272 methodOopDesc::method_from

JDK-4926272 : methodOopDesc::method_from_bcp is unsafe

Type: Bug
Component: hotspot
Sub-Component: runtime
Affected Version: hs13,hs19,5.0,7

Priority: P3
Status: Closed
Resolution: Fixed
OS: generic
CPU: generic

Submitted: 2003-09-22
Updated: 2014-03-21
Resolved: 2011-03-07

Versions (Unresolved/Resolved/Fixed)

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 6	JDK 7	Other
6u25Fixed	7Fixed	hs20Fixed

Related Reports

Duplicate :	JDK-6664184 - assert(" must own lock UNKNOWN") on jdi tests using CMS
Duplicate :	JDK-7012011 - crash while in debug mode of eclipse 3.5O
Duplicate :	JDK-6966167 - fatal error: must own lock Heap_lock
Relates :	JDK-7013008 - assert(method == NULL \|\| check_method(method, bcp)) failed: bcp must point into method
Relates :	JDK-4933250 - VM asserts at mutexLocker.cpp:99
Relates :	JDK-6952105 - TEST_BUG: testcase failure, not very often, com/sun/jdi/SuspendThreadTest.java
Relates :	JDK-6498878 - client compiler crashes on windows when dealing with breakpoint instructions

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 http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8012aa3ccede
20-01-2011
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.
14-01-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8012aa3ccede
14-01-2011
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.
11-03-2008
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;
11-03-2008
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.
21-02-2008
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)); }
21-02-2008
EVALUATION This needs to be discussed for tiger.
11-06-2004