PQ73487: APPSERVER CRASHES UNDER LOAD WITH SIGSEGV IN LIBJVM.A IN A GC HELPER THREAD.

 A fix is available

***SUPERCEDED*** 1.3.1 Java SDK, Java Tech Edition for WebSphere v5



APAR status
Closed as program error.

Error description
Problem Description:
AppServer restarts due to a SIGSEGV or Memory Access Failure
(on Windows) which terminates the java process.
Tue Apr 22 09:02:27 2003
SIGSEGV received at 0xd0f2cb18 in /usr/WebSphere/AppServer/java/
jre/bin/libjvm.a (jvm.dll on Windows)
Problem Summary:
For some versions of the jdk, it may show the following instead.
SIGSEGV received at 0xd0f2cb18 in /usr/WebSphere/AppServer/java/
jre/bin/libxhpi.a
.
The call stack for the crash in libjvm will be
    "GC Helper 1" sys_thread_t:0x38872F28
         ----- Native Stack -----
        at 0xD13B900C in localMark
        at 0xD13C2954 in parallelMark
        at 0xD13B81E4 in parallelMarkHelper
        at 0xD1393804 in gcHelper
        at 0xD1334314 in xmExecuteThread
.
The call stack in the libxhpi.a crash is as follows:
2XHCURRSYSTHD      "GC Helper 3" sys_thread_t:0x7263C950
3XHNATIVESTACK       Native Stack
NULL                 ------------
3XHSTACKLINE         at 0xD0F2D010 in DumpInitialDetails
3XHSTACKLINE         at 0xD0F2CBB8 in Diagnostics
3XHSTACKLINE         at 0xD3DD9F98 in dgGenerateJavacore
3XHSTACKLINE         at 0xD3DD8610 in dgDumpHandler
3XHSTACKLINE         at 0xD3DDC014 in abortJVM
3XHSTACKLINE         at 0xD3DDB914 in panicSignalHandler
3XHSTACKLINE         at 0xD0F7A8D8 in sysUnwindSignalCatchFrame
3XHSTACKLINE         at 0xD0F7AA9C in sysSignalCatchHandler
3XHSTACKLINE         at 0xD0F767B8 in userSignalHandler
3XHSTACKLINE         at 0xD0F76838 in intrDispatch
3XHSTACKLINE         at 0xD0F76E20 in intrDispatchMD
The reason the thread dump looks like this is that there is
a crash in the javacore processing.  To confirm that the real
problem is the crash in the .localmark process, either
set DISABLE_JAVADUMP=true to disable the javacore processing
and format the core or user.dmp file or check the errpt to
determine if the crash in the GC Helper thread doing a
.localmark call is the underlying signal (the signal that
caused the javacore processing to be triggered).
Problem Conclusion:
The solution for this is to upgrade to jdk ca131-20030329
cn131-20030329 (on Windows), or cx131-20030329 (Linux)
This is jdk defect SOV 52413.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: All WebSphere Application Server users of    *
*                 the IBM JDK prior to ca131-20030329.         *
****************************************************************
* PROBLEM DESCRIPTION: AppServer crashes under load with       *
*                      SIGSEGV in LIBJVM.A in a GC helper      *
*                      thread.                                 *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
AppServer restarts due to a SIGSEGV that terminates the jvm
process.
SIGSEGV received at 0xd0f2cb18 in /usr/WebSphere/AppServer/java/
jre/bin/libjvm.a .
For some versions of the jdk, SIGSEGV is received at
0xd0f2cb18 in /usr/WebSphere/AppServer/java/jre/bin/libxhpi.a
.
The call stack for the crash in libjvm will be
"GC Helper 1" sys_thread_t:0x38872F28
----- Native Stack -----
at 0xD13B900C in localMark
at 0xD13C2954 in parallelMark
at 0xD13B81E4 in parallelMarkHelper
at 0xD1393804 in gcHelper
at 0xD1334314 in xmExecuteThread
.
The call stack in the libxhpi.a crash is as follows:
2XHCURRSYSTHD      "GC Helper 3" sys_thread_t:0x7263C950
3XHNATIVESTACK       Native Stack
NULL                 ------------
3XHSTACKLINE         at 0xD0F2D010 in DumpInitialDetails
3XHSTACKLINE         at 0xD0F2CBB8 in Diagnostics
3XHSTACKLINE         at 0xD3DD9F98 in dgGenerateJavacore
3XHSTACKLINE         at 0xD3DD8610 in dgDumpHandler
3XHSTACKLINE         at 0xD3DDC014 in abortJVM
3XHSTACKLINE         at 0xD3DDB914 in panicSignalHandler
3XHSTACKLINE         at 0xD0F7A8D8 in sysUnwindSignalCatchFrame
3XHSTACKLINE         at 0xD0F7AA9C in sysSignalCatchHandler
3XHSTACKLINE         at 0xD0F767B8 in userSignalHandler
3XHSTACKLINE         at 0xD0F76838 in intrDispatch
3XHSTACKLINE         at 0xD0F76E20 in intrDispatchMD
The reason the thread dump looks like this is that there is
a crash in the javacore processing.  To confirm that the real
problem is the crash in the .localmark process, either
set DISABLE_JAVADUMP=true to disable the javacore processing
and format the core or user.dmp file or check the errpt to
determine if the crash in the GC Helper thread doing a
.localmark call is the underlying signal (the signal that
caused the javacore processing to be triggered).
Problem conclusion
The solution for this is to upgrade to jdk ca131-20030329
This is jdk defect SOV 52413.
Temporary fix Comments
APAR information
APAR number PQ73487
Reported component name WEBSPHERE AE AI
Reported component ID 5630A2200
Reported release 400
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2003-04-23
Closed date 2003-05-27
Last modified date 2003-08-28

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros
JDK          

SRLS

Fix information

Applicable component levels
R400 PSY    UP


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ73487
IBM Group: Software Group
Modified date: Aug 28, 2003