JVM Crash

[J Wallace]

Hi,

I'm running a Java 1.4.2 application on a Red Hat machine that causes the JVM to crash with a SIGSEGV error. -Xms is 64M and -Xmx is 128M. I first thought that the perm gen size was too low since it always has a high percentage (98/99%) when the JVM crashes. After reading more about the perm gen, though, I'm not so sure. Am I looking down the right path by thinking it may be the perm gen size being too low or is the percentage so high just because the JVM will resize it dynamically? When it crashes the perm gen's total size is around 10/11 MB and its usually 99% full.

Below are some snippets of the JVM's output.

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0xb7c70b4c, pid=5342, tid=2810452880
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_16-b05 mixed mode)
# Problematic frame:
# V  [libjvm.so+0x196b4c]
#

...

Heap
 def new generation   total 4608K, used 3372K [0xa7900000, 0xa7e00000, 0xa82d0000)
  eden space 4096K,  78% used [0xa7900000, 0xa7c27780, 0xa7d00000)
  from space 512K,  27% used [0xa7d80000, 0xa7da3ad8, 0xa7e00000)
  to   space 512K,   0% used [0xa7d00000, 0xa7d00000, 0xa7d80000)
 tenured generation   total 60544K, used 21376K [0xa82d0000, 0xabdf0000, 0xaf900000)
   the space 60544K,  35% used [0xa82d0000, 0xa97b0210, 0xa97b0400, 0xabdf0000)
 compacting perm gen  total 11264K, used 11159K [0xaf900000, 0xb0400000, 0xb3900000)
   the space 11264K,  99% used [0xaf900000, 0xb03e5c30, 0xb03e5e00, 0xb0400000)

...

---------------  S Y S T E M  ---------------
 
OS:Red Hat Enterprise Linux Client release 5 (Tikanga)
 
uname:Linux 2.6.18-8.1.8.el5 #1 SMP Mon Jun 25 17:06:19 EDT 2007 i686
libc:glibc 2.5 NPTL 2.5 
rlimit: STACK 10240k, CORE 0k, NPROC 16370, NOFILE 1024, AS infinity
load average:0.00 503...
 
CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2
 
Memory: 4k page, physical 1034572k(314260k free), swap 2096472k(2096472k free)
 
vm_info: Java HotSpot(TM) Client VM (1.4.2_16-b05) for linux-x86, built on Sep 17 2007 00:34:43 by unknown with unknown compiler
 

If it's not the perm gen, does anyone have any other suggestions?

[Henry Wong]

A segmentation violation is something that you should never get with Java. Log into bugs.sun.com, and search to see if there is a bug that is similar to what you are encountering. Check for any known work-arounds. If not, then report the bug...

Henry

[Nicholas Jordan]

I had some bulky code I wrote recently doing some thinking about an issue in a post and I intentionally left a recursive call such that it would either blow out the stacks or the jvm would have some mighty powerful optomization built in.

It crashed, I set it to a more sane loop construct, it ran - very well.

I suspect the ( what looks to me to be a segmentation violation ) which comes from memory hogging probably, would be better addressed by re-writing the app. Also we have an opportunity for Linux questions in a forum for that purpose.

please re-write the code line that is stretching the window thus:

vm_info: Java HotSpot(TM) Client VM (1.4.2_16-b05)\
for linux-x86, built on Sep 17 2007 00:34:43 by unknown with\
unknown compiler 

visit: Linux / UNIX at our facility.

[J Wallace]

Should I be concerned about the perm gen being at 99% capacity when the JVM crashes?

[Henry Wong]

Originally posted by J Wallace:
Should I be concerned about the perm gen being at 99% capacity when the JVM crashes?

Well, as mentioned, since a seg fault should never happen, the answer is "I don't know". You are basically speculating on a cause for something that should never happen.

Anyway, if you really believe that it is the permanent generation portion of the heap, you can increase it...

-XX:MaxPermSize=256m

This should raise it from the default size of 64 meg.

Henry