Red Hat Bugzilla – Bug 128729
Large java processes core dump on hugemem kernel
Last modified: 2007-11-30 17:07:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1)
Description of problem:
We have large weblogic 8.1sp2 and 8.1sp3 processes that occasionally
but regularly crash and core dump on the hugemem kernel. This happens
under Sun JVMs 1.4.2_04, 1.4.2_05, and jrockit 8.2. BEA tech support
has found a similar case and referred us to the "[PATCH] bogus
sigaltstack calls by rt_sigreturn" patch recently accepted into 2.6.7.
The client customer performed this patch (modified slightly because
of the differences in the code in 2.4AS3.0 kernel and stock 2.6) and
the problems seem to have gone away (no further tech support requests
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run large java apps on hugemem kernel with large amounts of RAM (we
have 12Gb in affected systems)
Actual Results: after a while, apps would core dump, with large call
Expected Results: app should run without issue
Happens 12Gb machines, and 36Gb machines.
Like to add myself to this. Our weblogic server crashes "every so often" for no apparent
reason leaving a large core file.
OS : 2.4.21-15.ELhugemem
MemTotal: 5931956 kB
Core was generated by `/usr/local/bea/jdk141_05/bin/java'.
Program terminated with signal 11, Segmentation fault.
FYI, here is the patch for those interested.
We will try to move off of the hugemem kernel before trying this patch. (fortunately that
is an option for us right now)
After reading the patch and this bug, I felt pretty sure that our problem was related to
this hugemem kernel problem, but after switching to the smp kernel...the problem is still
happening. The only noticible differences are now the stack trace produces this
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# Java VM: Java HotSpot(TM) Client VM (1.4.1_05-b01 mixed mode)
# Error ID: 43113F32554E54494D45110E4350500305
# Problematic Thread: prio=1 tid=0x0x83f6028 nid=0x7a0 runnable
and the crashes now happen at a regular time (around midnight) instead of at random
Seems closed. There is a fix to the AS hugemem kernel as of kernel
update 18 (the beta for U3). The U3 kernel has solved our problems.
Closing per above comment (seems to be dup of bug 123253).
*** This bug has been marked as a duplicate of 123253 ***