JDK-4951689 : JVM crashes during deoptimization phase
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.2,1.4.2_01,1.4.2_02
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,windows_2000
  • CPU: x86
  • Submitted: 2003-11-10
  • Updated: 2012-10-08
  • Resolved: 2004-06-25
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.2_06 06Fixed
Related Reports
Relates :  
JDK-6216196 - jvm crashes filling in exception trace by accessing zombie method.
Relates :  
JDK-6209701 - jvm crashes failing "unsafe access to zombie method" gaurantee
Description
Linux version:
 Linux version 2.4.9-e.3smp (###@###.###) (gcc 
 version 2.96 20000731 (Red Hat Linux 7.2 2.96-108.1)) #1 SMP Fri May 3 
 16:48:54 EDT 2002  - RedHat AS 2.1 - hyperthreading was on.



After a 14 hour run, the memory on the machine was about 
5M free (machine has 2Gb and the jvm heap is set  to 1024M) - the JVM 
crashed a few minutes ago (traffic was still running) with the following
error. The verbose gc log in attachment which also has the the crash report:

-----------------------------------------------------------------------
53479.741: [GC 53479.741: [ParNew: 16255K->0K(16320K), 0.0771970 secs] 
507744K->497333K(1048512K), 0.0773430 secs]
53480.563: [GC 53480.563: [ParNew: 16255K->0K(16320K), 0.0914510 secs] 
513589K->502901K(1048512K), 0.0915960 secs]
53481.733: [GC 53481.733: [ParNew: 16255K->0K(16320K), 0.0889060 secs] 
519157K->508893K(1048512K), 0.0890670 secs]
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Server VM (1.4.2_02-b03 mixed mode)
#
# Error ID: 434F444523414348450E43505000CF
#
# Problematic Thread: prio=1 tid=0x8fce1220 nid=0x2102 runnable
#

Heap at VM Abort:
Heap
  par new generation   total 16320K, used 6086K [0x44b20000, 0x45b20000, 
0x45b20000)
   eden space 16256K,  37% used [0x44b20000, 0x4512b0a8, 0x45b00000)
   from space 64K,   0% used [0x45b00000, 0x45b00000, 0x45b10000)
   to   space 64K,   0% used [0x45b10000, 0x45b10000, 0x45b20000)
  concurrent mark-sweep generation total 1032192K, used 508893K 
[0x45b20000, 0x84b20000, 0x84b20000)
  concurrent-mark-sweep perm gen total 34188K, used 24914K [0x84b20000, 
0x86c83000, 0x88b20000)


The "error id"     434F444523414348450E43505000CF
decodes to:     codeCache.cpp, 207


--------------------------------------------------
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_06 generic FIXED IN: 1.4.2_06 INTEGRATED IN: 1.4.2_06
26-06-2004
PUBLIC COMMENTS .
26-06-2004
EVALUATION e-mail inquiry[2nd] sent to cust to get the expected stack retrace/gdb data. ###@###.### 2003-11-24 e-mail inquiry[3rd] sent to cust to get the expected data ###@###.### 2003-12-01 Should the JDC member that also saw this bug on windows happen to read this evaluation if you are able to reproduce this problem and think it will be reproducible here, please send an email message to the feedback alias. We are very interested in getting a testcase for this bug. ###@###.### 2004-01-08 This bug is caused by a deoptimization occuring while we waited for a lock in reresolve_call_site. There was code that attempted to correct for this but since it did not reread the frame it was essentially useless. This was automatically fixed in tiger by lazy deopt changes. ###@###.### 2004-04-15
15-04-2004