JDK-4876597 : AsyncGetCallTrace crash in forte_is_walkable_frame()
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmpi
  • Affected Version: 1.4.2_02
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9
  • CPU: generic
  • Submitted: 2003-06-10
  • Updated: 2003-06-18
  • Resolved: 2003-06-18
Related Reports
Duplicate :  
Description
###@###.### 2003-06-10

An internal Analyzer tool customer, Eileen Loh, reported a crash with my
latest batch of Forte fixes. This crash was due to a SIGBUS signal received
in the forte_is_walkable_frame() routine.

Eileen was running the Mantis-B24 version of my fixes:

java version "1.4.2-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-rc-b24)
Java HotSpot(TM) Server VM (build 20030516194907.dcubed.forte-batch-20030519-product, mixed mode)
Built on May 16 2003 21:40:36 by unknown with Workshop 5.2 compat=5

She was running on machine lifeboat.sfbay:

SunOS lifeboat 5.9 Generic_112233-03 sun4u sparc SUNW,Sun-Fire-880

She was trying to collect data from the SunOne appserver and is consistently
getting a crash. The JDK she was running is the J2SDK1.4.2_02 prebuild along
with the collector bits from
/net/feynman.sfbay/export/set/rex/dist.S1S8Analyzer.rc1/sparc-S2/bin

In my last Mantis stress run there were a total of 2 failures due to a
SIGBUS in forte_is_walkable_frame() during the entire 72 hour run. One
was with the Server VM product bits and one was with the Server VM jvmg
bits. I squirreled away thread dumps for both of these crashes, but I
didn't save the core files.

For Eileen's failure on machine lifeboat, I have attached the following
files:

    hs_err_pid19678.log
    threads.log.lifeboat

Comments
EVALUATION ###@###.### 2003-06-11 I analyzed the core file provided by Eileen and determined that the SIGBUS actually happened in forte_is_valid_method() which is inlined. See the attached notes.lifeboat for the gory details. The method parameter passed the Universe::heap()->is_in(method) call but the VM crashed trying to retrieve the klass() of the method: oop(method)->klass() != Universe::methodKlassObj() || The method parameter was 0x547a3c09 which is not aligned on a double-word boundary which is a requirement for non-LP64 SPARC machines. It looks like we need one more sanity check in this routine. ###@###.### 2003-06-18 This bug describes a minor tweak to the work done in the following bug: 4762958 3/3 occasional crashes/deadlocks from AsyncGetCallTrace() In order to make the bookkeeping easier on the Mantis-Update2 team, I'm closing this bug as a duplicate of 4762958.
11-06-2004

SUGGESTED FIX ###@###.### 2003-06-11 Here are the context diffs for the suggested fix: ------- src/share/vm/includeDB_core ------- *** /tmp/diraahH Wed Jun 11 14:30:05 2003 --- includeDB_core Wed Jun 11 11:39:54 2003 *************** *** 862,867 **** --- 862,868 ---- forte.cpp jvmpi.inline.hpp forte.cpp oop.inline.hpp forte.cpp oop.inline2.hpp + forte.cpp space.hpp forte.cpp thread.hpp forte.cpp universe.inline.hpp forte.cpp vframe.hpp ------- src/share/vm/prims/forte.cpp ------- *** /tmp/dBIa4hH Wed Jun 11 14:31:16 2003 --- forte.cpp Wed Jun 11 11:39:30 2003 *************** *** 121,127 **** // The methodOop is extracted via an offset from the current // interpreter frame. With AsyncGetCallTrace() the interpreter // frame may still be under construction so we need to make ! // sure that we got an oop before we try to use it. !Universe::heap()->is_in(method) || // klass() does not need vtable dispatch so check before is_perm() oop(method)->klass() != Universe::methodKlassObj() || --- 121,128 ---- // The methodOop is extracted via an offset from the current // interpreter frame. With AsyncGetCallTrace() the interpreter // frame may still be under construction so we need to make ! // sure that we got an aligned oop before we try to use it. ! (ALIGN_ALL_OBJECTS && !Space::is_aligned(method)) || !Universe::heap()->is_in(method) || // klass() does not need vtable dispatch so check before is_perm() oop(method)->klass() != Universe::methodKlassObj() ||
11-06-2004

PUBLIC COMMENTS .
10-06-2004