Linux version:
 Linux version 2.4.9-e.3smp (  xxxxx@xxxxx  ) (gcc 
 version 2.96 20000731 (Red Hat Linux 7.2 2.96-108.1)) #1 SMP Fri May 3 
 16:48:54 EDT 2002  -  customer  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


--------------------------------------------------

N/A

e-mail inquiry[2nd] sent to cust to get the expected stack retrace/gdb data.

  xxxxx@xxxxx   2003-11-24
e-mail inquiry[3rd] sent to cust to get the expected data
  xxxxx@xxxxx   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.

  xxxxx@xxxxx   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.


  xxxxx@xxxxx   2004-04-15

I'm having the same errorId
     [java] # Java VM: Java HotSpot(TM) Client VM 
(1.4.1_03-b02 mixed mode)
     [java] #
     [java] # Error ID: 434F444523414348450E43505000CF
     [java] #
     [java] # Problematic Thread: prio=5 tid=0x2C13E4C8 
nid=0x3f0 runnable 
on WIN2K

This happened on Windows XP SP1 Professional
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_02-b03 
mixed mode)
#
# Error ID: 434F444523414348450E43505000CF
#
# Problematic Thread: prio=2 tid=0x06f7b058 
nid=0x77c runnable 
#

Heap at VM Abort:
Heap
 def new generation   total 1280K, used 144K 
[0x10010000, 0x10170000, 0x104f0000)
  eden space 1152K,   1% used [0x10010000, 
0x10014100, 0x10130000)
  from space 128K, 100% used [0x10130000, 
0x10150000, 0x10150000)
  to   space 128K,   0% used [0x10150000, 
0x10150000, 0x10170000)
 tenured generation   total 14060K, used 10754K 
[0x104f0000, 0x112ab000, 0x14010000)
   the space 14060K,  76% used [0x104f0000, 
0x10f70960, 0x10f70a00, 0x112ab000)
 compacting perm gen  total 13056K, used 13053K 
[0x14010000, 0x14cd0000, 0x18010000)
   the space 13056K,  99% used [0x14010000, 
0x14ccf770, 0x14ccf800, 0x14cd0000)

We have the same problem under Solaris (SunOS 5.
8)

java version "1.4.2_02"
Java(TM) 2 Runtime Environment, Standard Edition 
(build 1.4.2_02-b03)
Java HotSpot(TM) Client VM (build 1.4.2_02-b03, 
mixed mode)

#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.
2_02-b03 mixed mode)
#
# Error ID: 434F444523414348450E43505000CF 01
#
# Problematic Thread: prio=5 tid=0x002c7dc8 
nid=0x3bd runnable 
#

Heap at VM Abort:
Heap
 def new generation   total 2112K, used 459K 
[0xf1400000, 0xf1620000, 0xf1b10000)
  eden space 2048K,  19% used [0xf1400000, 
0xf1462fb8, 0xf1600000)
  from space 64K, 100% used [0xf1600000, 
0xf1610000, 0xf1610000)
  to   space 64K,   0% used [0xf1610000, 
0xf1610000, 0xf1620000)
 tenured generation   total 10840K, used 8457K 
[0xf1b10000, 0xf25a6000, 0xf5400000)
   the space 10840K,  78% used [0xf1b10000, 
0xf2352618, 0xf2352800, 0xf25a6000)
 compacting perm gen  total 5888K, used 5845K 
[0xf5400000, 0xf59c0000, 0xf9400000)
   the space 5888K,  99% used [0xf5400000, 
0xf59b5440, 0xf59b5600, 0xf59c0000)
Abort

We also have the same problem under Red Hat Enterprise Linux
2.1 with JDK 1.4.2_02.
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_02-b03 mixed mode)
#
# Error ID: 434F444523414348450E43505000CF
#
# Problematic Thread: prio=1 tid=0x085ebe40 nid=0x7fa7 runnable 
#

Heap at VM Abort:
Heap
 def new generation   total 576K, used 142K [0x44870000,
0x44910000, 0x44d50000)
  eden space 512K,  21% used [0x44870000, 0x4488b750,
0x448f0000)
  from space 64K,  51% used [0x448f0000, 0x448f8488, 0x44900000)
  to   space 64K,   0% used [0x44900000, 0x44900000, 0x44910000)
 tenured generation   total 5328K, used 4368K [0x44d50000,
0x45284000, 
0x48870000)
   the space 5328K,  81% used [0x44d50000, 0x451941e0,
0x45194200, 0x45284000)
 compacting perm gen  total 12288K, used 12189K [0x48870000,
0x49470000, 
0x4c870000)
   the space 12288K,  99% used [0x48870000, 0x49457408,
0x49457600, 0x49470000)

Same problem with JDK 1.4.1_01 on Windows NT:
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.1-b21 
mixed mode)
#
# Error ID: 434F444523414348450E43505000CF
#
# Problematic Thread: prio=4 tid=0x14600A70 
nid=0x153 sleeping
#

I meet the same problem under Microsoft Windows  
Server 2003 Enterprise Edition

The error is not always happen and may present itself 
several miniutes after I launch our whole "system" .
The system is too large to distribute for some 
commerce reason. I will offer the test, if I have time to 
do some clipping.

I've seen this bug on solaris. Don't yet have a workaround,
but I do have a core file from the last crash.  Where can I
send the core (~ 480mb uncompressed).

The similar error occur in the folowing environment
Linux version 2.4.22-1.2115.nptl 
(bhcompile@daffy.perf.redhat.com) (gcc version 3.2.3 
20030422 (Red Hat Linux 3.2.3-6)) #1 Wed Oct 29 
15:42:51 EST 2003

This is a error log
#
# 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_03-b02 
mixed mode)
#
# Error ID: 
53484152454432554E54494D450E435050014F
#
# Problematic Thread: prio=1 tid=0x4f2ceec8 
nid=0xd82 runnable 
#

Heap at VM Abort:
Heap
 def new generation   total 6528K, used 4856K 
[0x44770000, 0x44e80000, 0x44e80000)
  eden space 5824K,  83% used [0x44770000, 
0x44c2e228, 0x44d20000)
  from space 704K,   0% used [0x44d20000, 
0x44d20000, 0x44dd0000)
  to   space 704K,   0% used [0x44dd0000, 
0x44dd0000, 0x44e80000)
 tenured generation   total 58304K, used 58303K 
[0x44e80000, 0x48770000, 0x48770000)
   the space 58304K,  99% used [0x44e80000, 
0x4876fe98, 0x48770000, 0x48770000)
 compacting perm gen  total 38400K, used 38252K 
[0x48770000, 0x4acf0000, 0x4c770000)
   the space 38400K,  99% used [0x48770000, 
0x4accb1e0, 0x4accb200, 0x4acf0000)
/opt/jboss-3.2.2/bin/run.sh: line 192:  3458 
Abortado                $JAVA $JAVA_OPTS -
classpath "$JBOSS_CLASSPATH" org.jboss.Main "$@"

Same problem on WindowsNT, java 1.4.1_05, happens very rarely and is not reproducible, sorry...

#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.1_05-b01 mixed mode)
#
# Error ID: 434F444523414348450E43505000CF
#
# Problematic Thread: prio=2 tid=0x007DD730 nid=0x283 runnable
#

Heres my example

#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode)
#
# Error ID: 434F444523414348450E43505000CF 01
#
# Problematic Thread: prio=5 tid=0x00391538 nid=0x2d runnable 
#

Heap at VM Abort:
Heap
 def new generation   total 2176K, used 2175K [0xf1800000, 0xf1a30000, 0xf1f10000)
  eden space 2112K,  99% used [0xf1800000, 0xf1a0fff0, 0xf1a10000)
  from space 64K, 100% used [0xf1a10000, 0xf1a20000, 0xf1a20000)
  to   space 64K,   0% used [0xf1a20000, 0xf1a20000, 0xf1a30000)
 tenured generation   total 16800K, used 10895K [0xf1f10000, 0xf2f78000, 0xf5800000)
   the space 16800K,  64% used [0xf1f10000, 0xf29b3f70, 0xf29b4000, 0xf2f78000)
 compacting perm gen  total 12800K, used 12730K [0xf5800000, 0xf6480000, 0xf9800000)
   the space 12800K,  99% used [0xf5800000, 0xf646e810, 0xf646ea00, 0xf6480000)
Abort (core dumped)

I had one too.

Just happened to us

Solaris 8

#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_04-b05 mixed mode)
#
# Error ID: 434F444523414348450E43505000CF 01
#
# Problematic Thread: prio=5 tid=0x00818e10 nid=0x135 runnable
#

Heap at VM Abort:
Heap
 def new generation   total 254464K, used 28732K [0xb5400000, 0xc5400000, 0xc5400000)
  eden space 246784K,   8% used [0xb5400000, 0xb6897068, 0xc4500000)
  from space 7680K, 100% used [0xc4500000, 0xc4c80000, 0xc4c80000)
  to   space 7680K,   0% used [0xc4c80000, 0xc4c80000, 0xc5400000)
 tenured generation   total 786432K, used 510115K [0xc5400000, 0xf5400000, 0xf5400000)
   the space 786432K,  64% used [0xc5400000, 0xe4628e80, 0xe4629000, 0xf5400000)
 compacting perm gen  total 14336K, used 14094K [0xf5400000, 0xf6200000, 0xf9400000)
   the space 14336K,  98% used [0xf5400000, 0xf61c3900, 0xf61c3a00, 0xf6200000)

I'm praying this is finally fixed in 1.4.2_06. I've had great success reproducing this bug in Eclipse (2.13 & 3.1) while running the Debugger on a hard-working multi-threaded application (sorry, can't release all the source here). It tends to happen more when I have no breakpoints set. I've gotten running all released JVMs 1.4.1_05 and up (1.5 not included of course).

#
# 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_06-b03 mixed mode)
#
# Error ID: 53484152454432554E54494D450E435050014F
#
# Problematic Thread: prio=1 tid=0x4f4c3680 nid=0xc37 runnable
#

Heap at VM Abort:
Heap
 def new generation   total 3712K, used 2123K [0x44930000, 0x44d30000,
0x45040000)
  eden space 3328K,  55% used [0x44930000, 0x44afe400, 0x44c70000)
  from space 384K,  71% used [0x44cd0000, 0x44d14b98, 0x44d30000)
  to   space 384K,   0% used [0x44c70000, 0x44c70000, 0x44cd0000)
 tenured generation   total 32032K, used 20129K [0x45040000,
0x46f88000, 0x48930000)
   the space 32032K,  62% used [0x45040000, 0x463e8628, 0x463e8800, 
0x46f88000)
 compacting perm gen  total 18944K, used 18718K [0x48930000,
0x49bb0000, 0x4c930000)
   the space 18944K,  98% used [0x48930000, 0x49b77be8, 0x49b77c00, 
0x49bb0000)

Heap at VM Abort:
Heap
 def new generation   total 3712K, used 2123K [0x44930000, 0x44d30000,
0x45040000)
  eden space 3328K,  55% used [0x44930000, 0x44afe400, 0x44c70000)
  from space 384K,  71% used [0x44cd0000, 0x44d14b98, 0x44d30000)
  to   space 384K,   0% used [0x44c70000, 0x44c70000, 0x44cd0000)
 tenured generation   total 32032K, used 20129K [0x45040000,
0x46f88000, 0x48930000)
   the space 32032K,  62% used [0x45040000, 0x463e8628, 0x4

#
# 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_06-b03 mixed mode)
#
# Error ID: 53484152454432554E54494D450E435050014F
#
# Problematic Thread: prio=1 tid=0x4f4c3680 nid=0xc37 runnable
#

Heap at VM Abort:
Heap
 def new generation   total 3712K, used 2123K [0x44930000, 0x44d30000,
0x45040000)
  eden space 3328K,  55% used [0x44930000, 0x44afe400, 0x44c70000)
  from space 384K,  71% used [0x44cd0000, 0x44d14b98, 0x44d30000)
  to   space 384K,   0% used [0x44c70000, 0x44c70000, 0x44cd0000)
 tenured generation   total 32032K, used 20129K [0x45040000,
0x46f88000, 0x48930000)
   the space 32032K,  62% used [0x45040000, 0x463e8628, 0x463e8800, 
0x46f88000)
 compacting perm gen  total 18944K, used 18718K [0x48930000,
0x49bb0000, 0x4c930000)
   the space 18944K,  98% used [0x48930000, 0x49b77be8, 0x49b77c00, 
0x49bb0000)

Heap at VM Abort:
Heap
 def new generation   total 3712K, used 2123K [0x44930000, 0x44d30000,
0x45040000)
  eden space 3328K,  55% used [0x44930000, 0x44afe400, 0x44c70000)
  from space 384K,  71% used [0x44cd0000, 0x44d14b98, 0x44d30000)
  to   space 384K,   0% used [0x44c70000, 0x44c70000, 0x44cd0000)
 tenured generation   total 32032K, used 20129K [0x45040000,
0x46f88000, 0x48930000)
   the space 32032K,  62% used [0x45040000, 0x463e8628, 0x4

This bug is not yet Fixed sir!!!!!! Please check it i am facign this with [root@virtual bin]# java -version
java version "1.4.2_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)

Could anyone tell us the reason???????

Is it really fixed?
See the mail from user mandarsamant !!!

What could i say my client, about this bug?
Could he change the java patch level?

There are people reporting that this bug is not fixed in 1.4.2_06. They
are reporting that they are seeing error id: 53484152454432554E54494D450E435050014F

This is not the same as the original bug which was error id:

434F444523414348450E43505000CF

which is completely different. With no justification mallku_c added
an entry which includes the ...14F error id. This was a mistake on
his/her part as this is a completely unrelated problem. If you are
seeing thatr 14F error id you are not seeing this bug and you should
submit a new bug. Hopefully with either a way to reproduce it or
able to give us access to a core file.

This bug is _not_ fixed in _06. I have seen it several times on Windows 2000 platform.

#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode)
#
# Error ID: 434F444523414348450E43505000CF
#
# Problematic Thread: prio=4 tid=0x3d1b7010 nid=0x5c0 runnable 
#

Heap at VM Abort:
Heap
 def new generation   total 9216K, used 8045K [0x10010000, 0x10a00000, 0x12770000)
  eden space 8256K,  97% used [0x10010000, 0x107e8418, 0x10820000)
  from space 960K,   1% used [0x10910000, 0x109132d0, 0x10a00000)
  to   space 960K,   0% used [0x10820000, 0x10820000, 0x10910000)
 tenured generation   total 121024K, used 93224K [0x12770000, 0x19da0000,
0x30010000)
   the space 121024K,  77% used [0x12770000, 0x1827a0e8, 0x1827a200, 0x19da0000)
 compacting perm gen  total 19456K, used 19391K [0x30010000, 0x31310000, 0x34010000)
   the space 19456K,  99% used [0x30010000, 0x312ffe60, 0x31300000, 0x31310000)

Finally someone (rapulamies) who claims this isn't fixed in 1.4.2_06 who actually has the correct error id. Unfortunately since the the original testcase is fixed with 1.4.2_06 (and I just tried it again) this means another bug with the same symptom. This is not too surprising since the error id is basically a report that  invariant about the code cache has been violated. Several different bugs having this same symptom have been fixed. I was sure hoping we had the last one but apparently not. So if you have the ...00CF error code and are using 1.4.2_06  and have a test case or a stack dump or a core file please find a way to get it to us. 

Could this bug be reopened please?
Let me know how to get a core dump or a stack trace and I
will try to get one.

rapulamies thanks for your response. I can't reopen the bug but I can 
create a new one. Since you are on windows you can't get a core 
dump but you should be able to get a stack dump. Run the java 
with the additional option -XX:+ShowMessageBoxOnError  if you 
happen to have a debugger (windbg, or visual studio) in your path
then you will just be able to click the button that appears when
it fails to start the debugger. (If you don't have visual studio you can
download windbg from microsoft site). If you don't have a debugger
in your path then you'll have to use the process manager to find
the process of the java program then start windbg and attach to
that process. Once you've done that you need to find the thread
that failed. In the example you provide the thread id is described
in the line "Problematic thread". You'll need to select that thread
and ask for its call stack. I hope this helps. I can't give my real email
address here but you can contact me at spamsink@starband.net
and we can try and get this resolved.

Here

Here's the stack trace of the problematic thread. I seem to be missing some debug symbols, so I don't know if this is useful...

JVM! 08047d0c()
JVM! 0803492b()
00a9b5e2()
00a9bf80()
00a43230()
00a42f2a()
00a42f2a()
00a43230()
00a43230()
00a43230()
00a43230()
00a42fab()
00a42e53()
00a42eff()
00a43159()
00a401ae()
JVM! 08071309()
JVM! 080ac21e()
JVM! 08071216()
JVM! 08070f12()
JVM! 08070f4b()
JVM! 08089d3a()
JVM! 080cff57()
JVM! 080cff25()
MSVCRT! 780085bc()
KERNEL32! 7c4e987c()

The stack trace was useful. I'm able to see  what the cause is. This
particular failure (in 1.4.2_06 or later) is in the runtime for the
client compiler. Using -server with 1.4.2_06 or later will work around
this particular bug. (Note: the original bug, which is different, was 
filed against -server but was common to both compilers.). A new 
bug has been filed 6209701 which will track the fix to the problem
that rapulamies described. Thanks for providing the stack trace.

Very impressing fatcatair! Good luck hunting this one down, and thanks for the workaround suggestion...

I had this crash as well with 1.4.2_06-b03  *and* -server.

Linux Fedora Core 2, kernel 2.6.8-1.521smp, 

#
# 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_06-b03 mixed mode)
#
# Error ID: 434F444523414348450E43505000CF
#
# Problematic Thread: prio=1 tid=0xcfcfb940 nid=0x3571 runnable 
#

Heap at VM Abort:
Heap
 def new generation   total 17024K, used 9344K [0xd0f70000, 0xd21e0000, 0xd4850000)
  eden space 15168K,  49% used [0xd0f70000, 0xd16ce3c0, 0xd1e40000)
  from space 1856K,  99% used [0xd2010000, 0xd21dffb8, 0xd21e0000)
  to   space 1856K,   0% used [0xd1e40000, 0xd1e40000, 0xd2010000)
 tenured generation   total 146980K, used 130070K [0xd4850000, 0xdd7d9000, 0xf0f70000)
   the space 146980K,  88% used [0xd4850000, 0xdc7559e8, 0xdc755a00, 0xdd7d9000)
 compacting perm gen  total 18688K, used 18532K [0xf0f70000, 0xf21b0000, 0xf4f70000)
   the space 18688K,  99% used [0xf0f70000, 0xf218a070, 0xf218a200, 0xf21b0000)

From gdb:

Core was generated by `java -server -Xmx512m -Xloggc:/home/wish/log/Automaton-5b.gc -XX:+PrintGCDetail...'.

I'll past the stack in another comment (quite big doesn't feet in the 4000 characters here).

#0  0x007dc7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x0081be49 in raise () from /lib/tls/libc.so.6
#2  0x0081d872 in abort () from /lib/tls/libc.so.6
#3  0x004c52e8 in os::abort () from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#4  0x0035dc3a in report_error () from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#5  0x0035d69d in report_fatal () from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#6  0x0033a821 in CodeCache::find_blob () from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#7  0x0055e408 in vframeStreamCommon::fill_from_frame ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#8  0x0055e769 in vframeStreamCommon::next ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#9  0x003e0d54 in java_lang_Throwable::fill_in_stack_trace ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#10 0x003e30e6 in java_lang_Throwable::fill_in_stack_trace ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#11 0x0042cb24 in JVM_FillInStackTrace () from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#12 0x00f051cd in Java_java_lang_Throwable_fillInStackTrace ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/libjava.so
#13 0x01018b14 in ?? ()
#14 0xcfcfb9e0 in ?? ()
#15 0x0668f1c8 in ?? ()
#16 0xd16b9798 in ?? ()
#17 0x00f20ec0 in ?? ()
#18 0x0668f21c in ?? ()
#19 0xcbbd8240 in ?? ()
#20 0xcfcfb940 in ?? ()
#21 0x0668f208 in ?? ()
#22 0x003c245d in instanceKlass::find_method ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#23 0x003de604 in JavaCalls::call_helper () from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#24 0x004c478d in os::os_exception_wrapper ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#25 0x003de856 in JavaCalls::call () from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#26 0x003deb12 in JavaCalls::call_special ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#27 0x0038d7d7 in Exceptions::new_exception ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#28 0x0038d9c0 in Exceptions::new_exception ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#29 0x0038da0d in Exceptions::new_exception ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#30 0x003cfd1f in InterpreterRuntime::create_exception ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#31 0x00f20d37 in ?? ()
#32 0xcfcfb940 in ?? ()
#33 0x0061a88f in InlineImageParser::MAX_INPUT_LINE ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#34 0x00000000 in ?? ()
#35 0x00f20d02 in ?? ()
#36 0x00000003 in ?? ()
#37 0xd67be560 in ?? ()
#38 0x0668f4b0 in ?? ()
#39 0xf111367f in ?? ()

... many frames similar to below ...

#229 0x0668f7b8 in ?? ()
#230 0x00f4c900 in ?? ()
#231 0x00f2ac57 in ?? ()
#232 0x0668f7c0 in ?? ()
#233 0xf1d8b48c in ?? ()
#234 0x0668f7f4 in ?? ()
#235 0xf1d8b8a8 in ?? ()
#236 0xf2075014 in ?? ()
#237 0xf1d8b438 in ?? ()
#238 0x0668f7f4 in ?? ()
#239 0x0668f804 in ?? ()
#240 0x00f19204 in ?? ()
#241 0x00000000 in ?? ()
#242 0x00000000 in ?? ()
#243 0x00000000 in ?? ()
#244 0xd1705f10 in ?? ()
#245 0xd4913760 in ?? ()
#246 0x00719504 in __DTOR_END__ () from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so
#247 0x0668f864 in ?? ()
#248 0xcbbd8228 in ?? ()
#249 0x0668f8ac in ?? ()
#250 0x003de604 in JavaCalls::call_helper ()
   from /usr/java/j2sdk1.4.2_06/jre/lib/i386/server/libjvm.so

Well I see bentoi has found yet another failure on this path that again
is different. What a nice start to the new year. :-( This is a different
bug again and I've created a new bug 6216196 to track it. This one
unfortunately isn't immediately obvious as to a solution. This bug
affects code common to server and client compilers so -client might
not workaround it. However using -XX:-StackTraceInThrowable should work around it. If bentoi can provide any further infomation
please send email to my spamsink@starband.net address and
we can communicate in a more direct way than thru the bug 
database. 

This has not been fixed in 142_06 as i just got this when i used debugger with JBuilder.

Well suryapvs, what a useless report. Why not just say "me too". When you actually spend the time to RTF tbug report you will see that there 
are multiple bugs associated with this same error id (assuming you 
got the ...CF id and not the ...14F id). The errorid that is reported
basically encodes a source line in the VM that says ShouldNotReachHere. That piece of code is called by MANY places
in the VM and depending on the caller it signifies a DIFFERENT BUG. Get it? The same ID DOES NOT MEAN THE SAME BUG!
The original bug is in fact fixed in 1.4.2_6 as the reported provided
us with a test case. Since that time two more reports of the same
error ID have been reported. One by rapulamies which is now
bug 6209701. This bug only can happen in the client compiler so
using -server will work around it. Unfortunately  bentoi found 
another way to produce this same ID with -server and unlike you
actually provided some useful information (a stack trace) and
we can see that it is an entirely new bug 6216196 . Neither of
these new bugs has been fixed in a released vm .

Now  suryapvs if you want to be helpful and not just say "me too"
try and get a core dump/ stack trace and see which of these two
new bugs you have or if you have yet another new way of 
producing this same ID.

Hi ... reviewing this bug against a repeating issue that we have in a high volume environment.  The bug is sporatic, so it is difficult to envoke on command, although it happens reliably across one of 3 Tomcat servers within a 24 hour period.  


An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x77E418BB
Function=SleepEx+0x22
Library=C:\WINDOWS\system32\kernel32.dll

Current Java thread:
	at sun.nio.cs.StreamDecoder.read0(StreamDecoder.java:130)
	- locked <0x13fcf4d8> (a java.io.InputStreamReader)
	at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:117)
	at java.io.InputStreamReader.read(InputStreamReader.java:151)
	at com.identix.abis.util.xmlrpc.URLTransport.sendString(URLTransport.java:51)
	at com.identix.abis.util.xmlrpc.URLTransport.sendCall(URLTransport.java:30)
	at com.tm.xmlrpc.Call.sendCall(Call.java:125)
	at com.identix.abis.util.xmlrpc.XmlRpcClientThingMachines.executeCall(XmlRpcClientThingMachines.java:46)
	at com.identix.abis.util.xmlrpc.BaseXmlRpcClient$ExecutionThread.run(BaseXmlRpcClient.java:50)




Heap at VM Abort:
Heap
 def new generation   total 6592K, used 6591K [0x10010000, 0x10730000, 0x11c80000)
  eden space 5888K,  99% used [0x10010000, 0x105cfff8, 0x105d0000)
  from space 704K,  99% used [0x105d0000, 0x1067fff8, 0x10680000)
  to   space 704K,   0% used [0x10680000, 0x10680000, 0x10730000)
 tenured generation   total 58304K, used 40123K [0x11c80000, 0x15570000, 0x20010000)
   the space 58304K,  68% used [0x11c80000, 0x143aec20, 0x143aee00, 0x15570000)
 compacting perm gen  total 16640K, used 16422K [0x20010000, 0x21050000, 0x24010000)
   the space 16640K,  98% used [0x20010000, 0x210199b0, 0x21019a00, 0x21050000)

This will either dump out exactly here in kernel32 or within an Oracle type2 dependent dll every time.  It is always associated with a network communication, and appears to be tied to a wait + compacting perm gen at 99%

Is this the same issue as that which is characterized here?

We are running 1.4.2_04

Thanks

Aughh!

Hi jauzenn. Your failure has nothing to do with the bug(s) properly
described by your failure. Your failure looks to be one that would
typically produce the  ...14F error id. The bug has nothing in common with the situation in the failure described by the original failure. You wouldn't probably even had looked at this bug except for the fact that the nitwit  mandarsamant  posted a error dump
from  an unrelated bug which only served to add more confusion to this bug. Unofrtunately for you the symptoms you describe can be
covered by a multitude of different failures none of which are easy
to diagnose without a test case.