Unexpected Signal : 11
I have a critical java application running a sunOS 5.8 on X86, Java VM 1.4.2_03-b02. This application has been running for over a year without any problems and then it crashed with the following error report.
Unexpected Signal : 11 occurred at PC=0xDAD57500
Function=javax.swing.text.SimpleAttributeSet$EmptyAttributeSet.isDefined(Ljava/lang/Object;)Z (compiled Java code)
Library=(N/A)
Current Java thread:
Dynamic libraries:
0x8050000 java
0xdfb70000 /usr/lib/lwp/libthread.so.1
0xdfb60000 /usr/lib/libdl.so.1
0xdfab0000 /usr/lib/libc.so.1
0xdf740000 /usr/j2sdk1.4.2_03/jre/lib/i386/client/libjvm.so
0xdf720000 /usr/lib/libCrun.so.1
0xdf700000 /usr/lib/libsocket.so.1
0xdf650000 /usr/lib/libnsl.so.1
0xdf630000 /usr/lib/libm.so.1
0xdf610000 /usr/lib/libsched.so.1
0xdfa80000 /usr/lib/libw.so.1
0xdf5d0000 /usr/lib/libmp.so.2
0xdf5b0000 /usr/j2sdk1.4.2_03/jre/lib/i386/native_threads/libhpi.so
0xdf550000 /usr/j2sdk1.4.2_03/jre/lib/i386/libverify.so
0xdf510000 /usr/j2sdk1.4.2_03/jre/lib/i386/libjava.so
0xdf4e0000 /usr/j2sdk1.4.2_03/jre/lib/i386/libzip.so
0xdf1a0000 /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2
0xdcf00000 /usr/j2sdk1.4.2_03/jre/lib/i386/libawt.so
0xdce90000 /usr/j2sdk1.4.2_03/jre/lib/i386/libmlib_image.so
0xdce30000 /usr/j2sdk1.4.2_03/jre/lib/i386/motif21/libmawt.so
0xdcc70000 /usr/dt/lib/libXm.so.4
0xdaba0000 /usr/openwin/lib/libXt.so.4
0xdcc30000 /usr/openwin/lib/libXext.so.0
0xdcc10000 /usr/openwin/lib/libXtst.so.1
0xdab20000 /usr/openwin/lib/libX11.so.4
0xdaac0000 /usr/openwin/lib/libdps.so.5
0xdaaa0000 /usr/openwin/lib/libSM.so.6
0xdaa80000 /usr/openwin/lib/libICE.so.6
0xda9d0000 /usr/j2sdk1.4.2_03/jre/lib/i386/libfontmanager.so
0xda9a0000 /usr/openwin/lib/locale/common/xlibi18n.so.2
0xda980000 /usr/openwin/lib/locale/iso8859-1/xomEuro.so.2
0xda960000 /usr/lib//liblayout.so
0xda920000 /usr/openwin/lib/locale/common/ximlocal.so.2
0xd23e0000 /usr/j2sdk1.4.2_03/jre/lib/i386/libnet.so
0xd23c0000 /usr/j2sdk1.4.2_03/jre/lib/i386/librmi.so
Heap at VM Abort:
Heap
def new generationtotal 576K, used 161K [0xd2400000, 0xd24a0000, 0xd24a0000)
eden space 512K, 19% used [0xd2400000, 0xd2418698, 0xd2480000)
from space 64K, 99% used [0xd2480000, 0xd248fff8, 0xd2490000)
tospace 64K,0% used [0xd2490000, 0xd2490000, 0xd24a0000)
train generationtotal 5696K, used 3416K [0xd24a0000, 0xd2a30000, 0xd6800000)
compacting perm gen total 8192K, used 7939K [0xd6800000, 0xd7000000, 0xda800000)
the space 8192K, 96% used [0xd6800000, 0xd6fc0fc0, 0xd6fc1000, 0xd7000000)
Local Time = Thu Jun 2 14:00:36 2005
Elapsed Time = 1206
#
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002EF
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_03-b02 mixed mode)
#
Can any one tell me what may have caused this error? I can't affort to have it happen again.
Thanks
[3245 byte] By [
jeppsonjfa] at [2007-10-1 15:47:23]
Ok, this is a shot in the dark, so don't take this post too very seriously.
First, the part that I'm certain about: Obviously, the problem isn't an exception with a stack trace... this is the JVM itself blowing up. I've seen this kind of problem before and it's almost certainly not your Java program's fault.
Now, the shot in the dark: I had a Linux machine blow up on me the other day and I was looking for hardware testing solutions. I found the following page:
http://www-106.ibm.com/developerworks/library/l-hw1/
that suggested hitting the machine with a continuous kernel compile and that, if one received the message "gcc: Internal compiler error: program cc1 got fatal signal 11", that the CPU was almost certainly flaky and would need replacing. I know that gcc's exit signals and Java's exit signals really have nothing to do with each other and that these are two different OSes, but three things make me think of this. 1) The signal number is 11, 2) both programs died after receiving an unexpected error (despite the fact that they should run pretty much indefinitely), and 3) the JVM died in a very serious and unpleasant way after running just fine for a very long time.
As an afterthought, I also don't know what resources the JVM may be using for its JIT compiling... if it's using gcc on your system, the signal numbers could have something to do with each other.
I know that this is a wild stab, but it didn't seem your thread had gotten responses and I figured it couldn't hurt. ;)
Good luck!
tvynra at 2007-7-10 23:38:56 >
What signal is #11?
$ uname -a
SunOS scd15 5.9 Generic_117171-02 sun4u sparc SUNW,Sun-Fire-15000
$ bash
bash-2.05$ kill -l
1) SIGHUP2) SIGINT3) SIGQUIT4) SIGILL
5) SIGTRAP6) SIGABRT7) SIGEMT8) SIGFPE
9) SIGKILL10) SIGBUS11) SIGSEGV12) SIGSYS
13) SIGPIPE14) SIGALRM15) SIGTERM16) SIGUSR1
17) SIGUSR218) SIGCHLD19) SIGPWR20) SIGWINCH
21) SIGURG22) SIGIO23) SIGSTOP24) SIGTSTP
25) SIGCONT26) SIGTTIN27) SIGTTOU28) SIGVTALRM
29) SIGPROF30) SIGXCPU31) SIGXFSZ32) SIGWAITING
33) SIGLWP34) SIGFREEZE35) SIGTHAW36) SIGCANCEL
37) SIGLOST39) SIGRTMIN40) SIGRTMIN+1 41) SIGRTMIN+2
42) SIGRTMIN+3 43) SIGRTMAX-3 44) SIGRTMAX-2 45) SIGRTMAX-1
46) SIGRTMAX
posman@linux:~/ivan> uname -a
Linux linux 2.6.4-52-default #1 Wed Apr 7 02:08:30 UTC 2004 i686 i686 i386 GNU/Linux
posman@linux:~/ivan> kill -l
1) SIGHUP2) SIGINT3) SIGQUIT4) SIGILL
5) SIGTRAP6) SIGABRT7) SIGBUS8) SIGFPE
9) SIGKILL10) SIGUSR111) SIGSEGV12) SIGUSR2
13) SIGPIPE14) SIGALRM15) SIGTERM17) SIGCHLD
18) SIGCONT19) SIGSTOP20) SIGTSTP21) SIGTTIN
22) SIGTTOU23) SIGURG24) SIGXCPU25) SIGXFSZ
26) SIGVTALRM27) SIGPROF28) SIGWINCH29) SIGIO
30) SIGPWR31) SIGSYS35) SIGRTMIN36) SIGRTMIN+1
37) SIGRTMIN+2 38) SIGRTMIN+3 39) SIGRTMIN+4 40) SIGRTMIN+5
41) SIGRTMIN+6 42) SIGRTMIN+7 43) SIGRTMIN+8 44) SIGRTMIN+9
45) SIGRTMIN+10 46) SIGRTMIN+11 47) SIGRTMIN+12 48) SIGRTMIN+13
49) SIGRTMIN+14 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8
57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4
61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX
posman@linux:~/ivan>
