JDK-6243940 : VMark/VTest SEGV with Mustang b28 on sol amd
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris,solaris_9,solaris_10
  • CPU: x86,sparc
  • Submitted: 2005-03-21
  • Updated: 2010-08-06
  • Resolved: 2005-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 6
6 b32Fixed
Related Reports
Duplicate :  
JDK-6247013 - atg crashed with fastdebug build on solaris sparc
Duplicate :  
JDK-6243119 - VolanoTest client crashed on Mustang build 28 64 bit Sparc
Relates :  
JDK-6244337 - Large perf regressions (2%-90%) in b28 (all platforms)
Relates :  
JDK-6250469 - Regression (SEGV) in Nightly hotswap tests
Relates :  
JDK-6250444 - Regression (SEGV) in Nightly popframe tests
Description
With Mustang b28, VMark and VTest failed on solaris amd platforms with 64 bits JVM.
Test machine: jtg-sunfire-3
VMark failed after 30 minutes with mustang b28.
# uname -a
SunOS jtg-sunfire-3 5.10 Generic i86pc i386 i86pc
Flags used: -d64 -XX:+UseSerialGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+ShowMessageBoxOnError -XX:+PrintGCTimeStamps
/usr/j2se/bin/java -d64 -version
java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b28)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-ea-b28, mixed mode)

I grab libjvm from /net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2005/20050319123751.rasbold.main_to_c2_baseline/solaris_amd64_compiler2/product/libjvm.so.gz and retested, the problem still happened after 17 minutes.
/usr/mustang_b28/bin/java -d64 -version
java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b28)
Java HotSpot(TM) 64-Bit Server VM (build 20050319123751.rasbold.main_to_c2_baseline, mixed mode)

Stack trace:
current thread: t@2
=>[1] ___nanosleep(0xfffffd7ffb3fc790, 0xfffffd7ffb3fc780, 0xfffffd7fff32b32c, 0xfffffd7fff33a7fa, 0x0, 0x4f), at 0xfffffd7fff339aba 
  [2] _sleep(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff32b340 
  [3] os::message_box(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffefd1dec 
  [4] VMError::show_message_box(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff028f84 
  [5] VMError::report_and_die(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff028c10 
  [6] JVM_handle_solaris_signal(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffebc3ada 
  [7] signalHandler(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffebc3c40 
  [8] __sighndlr(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff337e86 
  [9] call_user_handler(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff32d312 
  [10] sigacthandler(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff32d4f8 
  ---- called from signal handler with signal 11 (SIGSEGV) ------
  [11] memcpy(0xfffffd7fb24e9ae8, 0xfffffd7f78200000, 0xce9e0, 0xeee, 0x0, 0x1000), at 0xfffffd7fff2ba9a9 
  [12] Copy::pd_disjoint_words(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffeb2fe9b 
  [13] Generation::promote(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffee26e2b 
  [14] DefNewGeneration::copy_to_survivor_space(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffee0eaa8 
  [15] FastScanClosure::do_oop(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffee0f875 
  [16] InterpretedArgumentOopFinder::set(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffee1f1f4 
  [17] SignatureInfo::do_object(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffeb8306a 
  [18] SignatureIterator::parse_type(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffeb4bc07 
  [19] SignatureIterator::iterate_parameters(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffeb70385 
  [20] frame::oops_interpreted_arguments_do(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffed2ac7f 
  [21] frame::oops_interpreted_do(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffeb7eb68 
  [22] frame::oops_do_internal(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xfffffd7ffb3fd8a0, 0x45dae0, 0xfffffd7ffb3fd858), at 0xfffffd7ffeb4df57 
  [23] JavaThread::oops_do(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffeb8a716 
  [24] Threads::oops_do(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffec54c9d 
  [25] GenCollectedHeap::process_strong_roots(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffee22575 
  [26] DefNewGeneration::collect(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffee0e3f7 
  [27] GenCollectedHeap::do_collection(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffee22165 
  [28] TwoGenerationCollectorPolicy::satisfy_failed_allocation(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffedef9ac 
  [29] GenCollectedHeap::satisfy_failed_allocation(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffee22497 
  [30] VM_GenCollectForAllocation::doit(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff02943d 
  [31] VM_Operation::evaluate(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffebfc9f4 
  [32] VMThread::evaluate_operation(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffebfcb9e 
  [33] VMThread::loop(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffed80ef0 
  [34] VMThread::run(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffed8041b 
  [35] _start(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffecb2418 
  [36] _thr_setup(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff337b4b 
  [37] _lwp_start(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff337d80 

###@###.### 2005-03-21 23:21:39 GMT
Comments
EVALUATION This is caused by taking a safepoint when hitting a non-entrant nmethod after passing thru a i2c adapter. The nmethod that is non-entrant never took possession of the arguments and so the caller must gc the args (the interpreter). Two problems then exist: 1: the args are in compiled form and the interpreter form is dead so gc'ing them is useless. 2: the interpreter stack has been extended so the gc code uses the wrong stack pointer for finding the args. This causes the seg. fault. The fix is to make this path safepoint invisible so that we don't have to find the compiled form of the args. In addition for sanity sake the interpreter/stack walking code will be corrected so that the correct location of top of stack for the interpreter is found. ###@###.### 2005-03-28 18:53:38 GMT
28-03-2005