Java core dump size

From: Bob Bailin (72027.3605_at_compuserve.com)
Date: 10/27/04 

Date: Wed, 27 Oct 2004 17:04:33 GMT

I'm trying to get the Java version of BackupEdge's edgemenu
program to work from an X-Windows session. Right now,
from a SCO console X-Window, it starts up, displays most
of the colorful menu icons, and just hangs. None of the menu
buttons are responsive, and I can't force a close using the
windows task button in the upper left corner of its window.

I have to exit X-Windows to force the applet to close.

When I do this, half the time Java core dumps and leaves
a log file (hs_err_pid######.log) and a core file in /usr/java.

My problem is that the core file seems to consume all of the
available free space in my root filesystem, which is admittedly
undersized with only 780MB free at the moment. The latest
core file was 771MB when I stumbed upon it and quickly
deleted it. Yesterday while playing around with this problem,
I had only 440MB of free space and the system quickly
ground to a snail's pace when it dumped a 439MB core
file, amidst dozens of out of space warnings on the console.
(I've since moved some stuff to another fs.)

Looking at the log file, I see that it dumped due to an
unexpected signal 11, probably the entirely expected
result of closing an X-Windows session.

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x8CE8B971
Function=_XtBuildKeysymTables+0x1F1
Library=/udk//usr/lib/libXt.so.6.0

Current Java thread:
    at sun.awt.motif.MToolkit.run(Native Method)
    at java.lang.Thread.run(Thread.java:534)

Dynamic libraries:
0x8048000 <a.out>
0x80123000 /udk/usr/lib/libsocket.so.2
0x80135000 /udk/usr/lib/libnsl.so.1
0x80181000 /udk/usr/lib/libthread.so.1
0x80091000 /udk/usr/lib/libc.so.1
0x801a9000 /opt/java2-1.4.2/jre/lib/i386/client/libjvm.so
0x8064e000 /udk/usr/lib/libm.so.1
0x80672000 /udk//usr/lib/libC.so.1
0x806f6000 /opt/java2-1.4.2/jre/lib/i386/native_threads/libhpi.so
0x80702000 /udk/usr/lib/libdl.so.1
0x8070a000 /opt/java2-1.4.2/jre/lib/i386/libverify.so
0x8071c000 /opt/java2-1.4.2/jre/lib/i386/libjava.so
0x8073d000 /opt/java2-1.4.2/jre/lib/i386/libzip.so
0x8cbab000 /opt/java2-1.4.2/jre/lib/i386/libnet.so
0x8cbbc000 /udk/usr/lib/tcpip.so
0x8cbc0000 /opt/java2-1.4.2/jre/lib/i386/libawt.so
0x8cc50000 /opt/java2-1.4.2/jre/lib/i386/libmlib_image.so
0x8ccb3000 /udk//usr/lib/libXm.so.1.3
0x8ce51000 /udk//usr/lib/libXt.so.6.0
0x8cea2000 /udk//usr/lib/libXext.so.6.1
0x8ceaf000 /udk//usr/lib/libXtst.so.6.1
0x8ceb6000 /udk//usr/lib/libX11.so.6.1
0x8cf81000 /udk//usr/lib/libSM.so.6.0
0x8cf8b000 /udk//usr/lib/libICE.so.6.0
0x8cfa5000 /opt/java2-1.4.2/jre/lib/i386/motif12/libmawt.so
0x8d021000 /opt/java2-1.4.2/jre/lib/i386/libfontmanager.so
0x8d1da000 /opt/java2-1.4.2/jre/lib/i386/libdcpr.so
0x8d2ce000 /opt/java2-1.4.2/jre/lib/i386/libjpeg.so

Heap at VM Abort:
Heap
    def new generation total 3264K, used 1918K [0x844f0000, 0x84830000, 0x849d0000)
        eden space 3200K, 58% used [0x844f0000, 0x846c7f98, 0x84810000)
        from space 64K, 47% used [0x84810000, 0x84817928, 0x84820000)
        to space 64K, 0% used [0x84820000, 0x84820000, 0x84830000)
    tenured generation total 39012K, used 29235K [0x849d0000, 0x86fe9000, 0x884f0000)
        the space 39012K, 74% used [0x849d0000, 0x8665cf18, 0x8665d000, 0x86fe9000)
    compacting perm gen total 5888K, used 5661K [0x884f0000, 0x88ab0000, 0x8c4f0000)
        the space 5888K, 96% used [0x884f0000, 0x88a77430, 0x88a77600, 0x88ab0000)

Local Time = Wed Oct 27 12:17:08 2004
Elapsed Time = 664 (note: I let the app sit in a hung state for about 10 minutes before
exiting X-Windows)
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM
(SCO-UNIX-J2SE-1.4.2_04_*FCS-UW7_FCS-OSR5_BETA-LEGEND*_20040623 mixed mode)
#

Does Openserver 5.0.7 have a way to limit the size of core dumps?

Why would the core file be larger than physical memory (512MB)?
Why would the virtual memory be at least 771MB for a Java app?

Bob

Quantcast