Java discussions newsgroups
|Posted: Fri May 26, 2006 11:41 pm Post subject: JVM Experts -> Challanging IBM JVM segfault
We have a 100% java web application (running on Tomcat 5) that is
occasionally causing a JVM core dump on a single machine. (Redhat Linux
SIGSEGV received in ?? at 0xffffffff in ??. Processing terminated.
Full core dump is here:
This is a baffling problem that only occurs on a single machine (1 out
of 7). Due to client 'policies' I am not privy to the hardware, but I
do know it's a dual Xeon with hyperthreading enabled (appears as 4
We cannot reliably replicate the problem. IT recommends that we 'code
around' the issue in the application, however, I am convinced this
has nothing to do with the application which has never exhibited a
segfault on 6 other machines, some under much heavier load.
The problem has never occured on an identical software stack. Running
on a Compaq - single CPU Celeron (Coppermine) box.
IT is very inflexible and insists on using only RHES3 binaries. They
are unwilling to bend the rules (at least for us). In other words, we
cannot upgrade to the latest IBM JVM release, we cannot use a Sun JVM,
and we cannot use a different JVM that is not distributed through a
RedHat ES3 channel.
The ultimate goal would be to identify the problem and get Redhat
to update the kernel, lib, or JVM which would be downloaded via
- 100% java web app (no JNI, no system calls)
- Using JasperReports for PDF, JFreeChart for GANTT charts
- Running on Tomcat 5 (RHES3 tomcat5-5.0.28-2jpp_5rh)
- DB is MySQL 4.0.13 (only part that is not RHES3, don't ask :)
Here is the part of the core dump that is really interesting:
1HPTHDDETAILS Current Thread Details
3HPREGISTERS Register Values
3HPREGVALUES EAX : 00000000, EBX : B2B89EEC, ECX : B1467270
3HPREGVALUES EDX : B42A5EE8, ESI : B44E9520, EDI : B2B89AC0
3HPREGVALUES EBP : B35DEB48, ESP : B2B89BA0, EIP : FFFFFFFF
3HPREGVALUES EFLAGS : 00010292
3HPNATIVESTACK Native Stack of "http-(ip)-8080-Processor3" PID 1802
In each case:
- EIP is always FFFFFFFF
- EAX is always 00000000
- the value FFFFFFFF(eip) is always at the top of the stack.
- Under cxia32142-20050609, this problem would occur and the value of
EDX was always B42A5EE8.
- After upgrading to cxia32142-20050929 (via RHN) the problem still
occurs but the value of EDX is now B42A8EE8.
- The Processor that the runaway thread is on changes every time.
I can provide objdump segments of any shared library or binary listed.
A ThinkGeek gift certificate is waiting for anyone who can
conclusively solve this problem!!!
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum