PQ73487: APPSERVER CRASHES UNDER LOAD WITH SIGSEGV IN LIBJVM.A IN A GC HELPER THREAD. | |||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||
![]() 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 is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
SRLS
|
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
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.