JDK-4478223 : "oopmap not found" assertion failure in jvmpi heap dump collection
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_8
  • CPU: generic,sparc
  • Submitted: 2001-07-10
  • Updated: 2001-09-27
  • Resolved: 2001-09-27
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
1.4.0 beta3Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Problem: (see also 4469343) 
JProbe fails to get heap dump and VM crashes when traversing oops in the stack
frame of a thread exiting a compiled method during heap dump collection and got
"oopmap not found" assertion:

# assert(!precise || at(i)->offset() == pc_offset, "oopmap not found")
#
# Error happened during: post JVMPI heap dump
#
# Error ID:
/export/files/ladybird_fixes/src/share/vm/compiler/oopMap.cpp, 310 [
Patched ]

and
# assert(i < len, "oopmap not found")
#
# Error happened during: post JVMPI heap dump
#
# Error ID:
/export/files/ladybird_fixes/src/share/vm/compiler/oopMap.cpp, 309 [

(both with nid=0x4, i.e. the VMThread)

SharedRuntime::jvmpi_method_exit is NOT a leaf since safepoint can occur while
a thread is in jvmpi::post_method_exit_event.  One reason for that is that
jvmpi::post_event_vm_mode makes calls to ThreadStateTransition::transition(),
which allows safepoint to block.

As discussed with Dave Cox, it's better to make C1 to generate oopmap for 
method exit and define SharedRuntime::jvmpi_method_exit as a JRT_ENTRY for
Merlin.  If necessary, we can also port the fix to 1.3.1_02 patch.

We might have the same problem for monitor_exit, which is defined as a leaf,
but it's not when jvmpi monitor exit event is enabled.  So we might want
to do the same thing for monitor_exit.


mandy.chung@eng 2001-08-09

4489387 also reports the same problem but the test fails when running with
-Xrunhprof:cpu=times.  To reproduce the failure,

> cd /home/zzhang/bugs/footprint
> java_g -Xrunhprof:cpu=times -cp jmol-0.2/jars/jmol.jar
-Djmol.home=jmol-0.2 jmol.Jmol

HPROF ERROR: thread local table NULL in method exit cb5a0
HPROF ERROR: thread local table NULL in method exit cb5a0
HPROF ERROR: thread local table NULL in method exit cc2a0
HPROF ERROR : stack underflow in method exit
HPROF ERROR : stack underflow in method exit
default to Motif 2.1, os is: 5.8
#
# HotSpot Virtual Machine Error, assertion failure
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4-internal-debug mixed mode)
#
# assert(i < len, "oopmap not found")
#
# Error ID:
/export/hotspot/users1/mchung/merlin_baseline/src/share/vm/compiler/oopMap.cpp,
335 [ Patched ]
#
# Problematic Thread: prio=5 tid=0xc98d0 nid=0x4 runnable 
#
Dumping core....

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta3 FIXED IN: merlin-beta3 INTEGRATED IN: merlin-beta3
14-06-2004

EVALUATION Dave, I am assigning the bug to you since you have already talked to Mandy. And, I remember the discussion with Tom in the meeting. mohammad.gharahgouzloo@Eng 2001-07-10 In order to support jvmpi_method_exit as a JRT_ENTRY routine, it must be called from a C1 stub that uses the same frame as the nmethod so that deoptimization of the nmethod cannot occur during a safepoint within the jvmpi code. The stub preserves the method's result, calls jvmpi_method_exit, then restores the result before continuing in the nmethod to effect a return or rethrow an unhandled exception. Before calling jvmpi_method_exit, the stub preserves an oop result or pending exception in the current thread. ###@###.### 2001-09-11
11-09-2001