JDK-4491764 : JVMPI method entry, exit events cause client VM to crash with Unexpected Signal.
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmpi
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2001-08-14
  • Updated: 2024-04-12
  • Resolved: 2019-03-08
Related Reports
Relates :  
JDK-4478223 - "oopmap not found" assertion failure in jvmpi heap dump collection
Relates :  
JDK-4489387 - -Xrunhprof crashed jvm or got program run to hang
Relates :  
JDK-4507553 - VM hangs on Linux when running hprof
Relates :  
JDK-4507533 - HPROF: No heap dump generated (java.exe crashes or HPROF ERROR: heap dump size < 0)
Relates :  
JDK-4496749 - C2: missing METHOD_EXIT events
Description
Using 1.4.0-beta_refresh-b73 it seems that enabling method entry and
exit events is very unstable. Customer sees this both with hprof and their profiler product. We could reproduce this using  the latest build (73) of merlin-beta release on Solaris/Linux platforms. Please note this happens only with Client VM.

To run it with hprof :

/home/raghuv/jdk1.4/bin/java -Xrunhprof:cpu=times -jar SwingSet2.jar
HPROF ERROR: thread local table NULL in method exit 9dbb4
HPROF ERROR: thread local table NULL in method exit 9dbb4
HPROF ERROR: thread local table NULL in method exit 9e564
HPROF ERROR : stack underflow in method exit
HPROF ERROR : stack underflow in method exit

Unexpected Signal : 11 occurred at PC=0xFE59C7D4
Function=[Unknown. Nearest: JVM_IsInterrupted+0xC30]
Library=/home/raghuv/jdk1.4/jre/lib/sparc/client/libjvm.so


Dynamic libraries:
0x10000         /home/raghuv/jdk1.4/bin/java
0xff350000      /usr/lib/libthread.so.1
0xff390000      /usr/lib/libdl.so.1
0xff200000      /usr/lib/libc.so.1
0xff330000      /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
0xfe400000      /home/raghuv/jdk1.4/jre/lib/sparc/client/libjvm.so
0xff2d0000      /usr/lib/libCrun.so.1
0xff1e0000      /usr/lib/libsocket.so.1
0xff100000      /usr/lib/libnsl.so.1
0xff0d0000      /usr/lib/libm.so.1
0xff300000      /usr/lib/libw.so.1
0xff0b0000      /usr/lib/libmp.so.2
0xff080000      /home/raghuv/jdk1.4/jre/lib/sparc/native_threads/libhpi.so
0xff050000      /home/raghuv/jdk1.4/jre/lib/sparc/libverify.so
0xff020000      /home/raghuv/jdk1.4/jre/lib/sparc/libjava.so
0xfe7e0000      /home/raghuv/jdk1.4/jre/lib/sparc/libzip.so
0xfe150000      /home/raghuv/jdk1.4/jre/lib/sparc/libhprof.so
0xf3d00000      /home/raghuv/jdk1.4/jre/lib/sparc/libawt.so
0xfa480000      /home/raghuv/jdk1.4/jre/lib/sparc/libmlib_image.so
0xfc920000      /home/raghuv/jdk1.4/jre/lib/sparc/motif21/libmawt.so
0xf3a80000      /usr/dt/lib/libXm.so.4
0xfc810000      /usr/openwin/lib/libXt.so.4
0xfa7d0000      /usr/openwin/lib/libXext.so.0
0xfe100000      /usr/openwin/lib/libXtst.so.1
0xf3980000      /usr/openwin/lib/libX11.so.4
0xfa6a0000      /usr/openwin/lib/libdps.so.5
0xfa7b0000      /usr/openwin/lib/libSM.so.6
0xfa5d0000      /usr/openwin/lib/libICE.so.6
0xfa5a0000      /usr/openwin/lib/libdga.so.1
0xf3880000      /home/raghuv/jdk1.4/jre/lib/sparc/libfontmanager.so
0xfa460000      /home/raghuv/jdk1.4/jre/lib/sparc/libnio.so
0xfa440000      /usr/lib/libposix4.so.1
0xfa410000      /home/raghuv/jdk1.4/jre/lib/sparc/libnet.so
0xf43e0000      /usr/lib/libaio.so.1
0xf43c0000      /usr/lib//liblayout.so
0xf42b0000      /home/raghuv/jdk1.4/jre/lib/sparc/libjpeg.so
0xf43a0000      /home/raghuv/jdk1.4/jre/lib/sparc/libsunwjdga.so
0xf4290000      /home/raghuv/jdk1.4/jre/lib/sparc/libjdgaSUNWafb.so

Local Time = Tue Aug 14 11:42:07 2001
Elapsed Time = 180
#
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002D7 01
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.0-beta_refresh-b73 mixed mode)
#
# An error report file has been saved as hs_err_pid7834.log.
# Please refer to the file for further information.
#
Abort
 prithvi 89 =>

Please refer to Incident #129103 for this issue.


###@###.### 2001-08-15

The same test case when run on Linux with strace hangs instead of crash :

strace -o strace.out java -Xrunhprof:cpu=times -jar SwingSet2.jar

It just never got past the splash screen. No error messages and ps or top do not show any of the java threads consuming any CPU. The hanging situation is not consistent and can be more easily reproduced when run with strace utility.

Also, please note that this happens more with latest merlin-beta builds. I could n't reproduce it using build 65 & 73, but can reproduced more easily with build 74 & 75. Of course, it crashes eventually in the tests when it does n't hang.
Please note this is specific to Linux only. On other platforms, it just crashes.

Refer to Incident #129101 for hanging issue.
Comments
EVALUATION ###@###.### 2001-08-14 This is a duplicate for 4478223. I leave this bug open for now until 4478223 is resolved and we will see if there're any other issues. ###@###.### 2001-08-15 The same test case when run on Linux with strace hangs instead of crash : strace -o strace.out java -Xrunhprof:cpu=times -jar SwingSet2.jar It just never got past the splash screen. No error messages and ps or top do not show any of the java threads consuming any CPU. The hanging situation is not consistent and can be more easily reproduced when run with strace utility. Also, please note that this happens more with latest merlin-beta builds. I could n't reproduce it using build 65 & 73, but can reproduced more easily with build 74 & 75. Of course, it crashes eventually in the tests when it does n't hang. Please note this is specific to Linux only. On other platforms, it just crashes. ###@###.### 2001-09-26 Summary on the status on this bug: This bug involves fixes in 4 different areas and two areas are fixed by Dave Cox in C1: 4478223 2/3 "oopmap not found" assertion failure in jvmpi heap dump collection Compiler1 now uses a frameless stub to call SharedRuntime::jvmpi_method_exit, which may block, so that the compiled call site doesn't need an oop map and cannot be deoptimized. If the caller is returning an oop or rethrowing and exception, that oop is preserved in its thread's vm_result field. 4505853 3/3 JVMPI method enter event not always posted by compiled method If a C1-compiled synchronized method was deoptimized after calling monitorenter upon entry, jvmpi_method_entry was not called. This is fixed by using a special monitorenter stub for the SynchronizationEntryBCI when JVMPI method entry events are enabled and performing the JVMPI notification from the stub if its caller has been deoptimized. The other two areas are fixed in runtime and hprof: 4489387 2/2 -Xrunhprof crashed jvm or got program run to hang 1. VM hang due to ObjectMonitor::raw_enter() blindly cast a thread pointer to JavaThread*. It made a bad assumption that it must be called only by JavaThread. VMThread can also acquire a raw monitor when it posts a GC_START event to the agent, which enters a raw monitor for data synchronization. So fix the hotspot VM to check for the thread's type before casting. 2. Deadlock on a raw monitor. One thread is processing THREAD_END event and enter a raw monitor. While holding the lock, it makes JVMPI call (GetThreadLocalStorage) which gives a chance to the VM to block the thread for other operation such as GC. If the thread is blocked and start GC, VM Thread will post a GC_START event to the agent, which also acquires the raw monitor first before further processing. Fix hprof to make sure JVMPI calls are called while either not holding a lock or GC is disabled for that event. These fixes will be available in build 81. See 4489387 for detailed testing result. Here are the testing results on running hprof on SwingSet2 on various platforms with the following hprof options: -Xrunhprof:cpu=times -Xrunhprof:cpu=samples -Xrunhprof:heap=dump -Xrunhprof:heap=all 1) Solaris Sparc All except -Xrunhprof:heap=[dump,all] work fine. For -Xrunhprof:heap=[dump,all], we are getting intermittent errors and empty heap dump when running hprof on SwingSet2. One error is OutOfMemoryError exception during shutdown and thus no heap dump. The other error is HPROF ERROR: heap dump size < 0. A new bug 4507533 is filed for this heap dump problem. 2) WinNT Same result as Solaris Sparc. 3) Linux When running -Xrunhprof:cpu=[times,samples] on SwingSet2, the VM hangs or crashes. A new bug 4507553 is filed for the linux hang problem. When running -Xrunhprof:heap=[all,dump], no hang/crashes but got the hprof heap dump size < 0 error. ###@###.### 2001-10-25 Two bugs were filed to track the remaining Linux problem and empty heap dump problem in JDK 1.4 build 83. There are a few bugs fixed for Sitraka in Merlin RC1, including the Linux hang problem caused by the LinuxThread pthread lock problem (see 4461173). We will be sending the new VM binaries to Sitraka for further testing when those RC1 fixes are integrated in the new build. We will then base on the priority list from Sitraka to determine if we can close this bug or there are remaining problems needed to be fixed for Merlin.
11-06-2004
WORK AROUND This works fine with -server option even tough it raises lot of these messages : HPROF ERROR: method on stack top != method exiting.. Even with Client VM, it works fine when -Xint option is specified : /home/raghuv/jdk1.4/bin/java -Xrunhprof:cpu=times -Xint -jar SwingSet2.jar will not crash the VM.
11-06-2004