JDK-5074710 : JVM crash with jni_GetObjectField
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2_05
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2004-07-16
  • Updated: 2009-06-25
  • Resolved: 2004-12-07
Related Reports
Duplicate :  
Relates :  
Description
Customer is observing crahs with 1.4.1_04, 1.4.2_04 and 1.4.2-05 with similar stack trace with his application.  Attched test case to report but it does not results crash all the times. Whenever crash was observed we got core file, hs_err, pstack for each version of JVM on which customer application was tested.

We are unable to nail down what's wrong with jni_GetObjectField  and Java_java_net_PlainDatagramSocketImpl_peekData calls. These calls are common on all stack traces.

I have attached customer test case with which I am unable to see issue but customer has seen crash.

Following JVM flags were used:

-server -Xms100m -Xmx512m -XX:+OverrideDefaultLibthread -XX:+UseSignalChaining -XX:+UseParallelGC -XX:+UseAdaptiveSizePolicy

To use the class, you will need the JDMK 5.0 jars in the classpath, and the JVM params as above, and you will need to have an SNMP agent send a steady (e.g.: 20/s) stream of traps to the port that the class is listening on (as written, port 1062).

Please note customer was able to see the crash but was not consistent. However, whenever crash was seen the routines on stack are fairly common.

Knowing jni call on stack we suggested customer to use -Xcheck:jni flag while running the application to trap more information. But it didn't helped as no messages where shown when crash happened.

Comments
EVALUATION I can't reproduce it either. Can you find out from customer:- 1. Can he reproduce it with 1.5 beta? 2. Does it happen when not using any of the VM flags that were specified? 3. How long does it take for the app to crash? Thanks ###@###.### 2004-07-16 This bug nolonger reproduced with 6189687, please see the detail for that fix. Closed as duplicate. ###@###.### 2004-12-07 19:43:16 GMT
16-07-2004