Fixes are available
APAR status
Closed as program error.
Error description
DB2 trap with signal 11 (SEGV) when Federated is enabled. call stack similar to below: 00002B57012A3047 ossDumpStackTraceEx + 0x01f7 (/opt/ibm/db2/V9.5/lib64/libdb2osse.so.1) 00002B570129EBBC _ZN11OSSTrapFile6dumpExEmiP7siginfoPvm + 0x00b4 (/opt/ibm/db2/V9.5/lib64/libdb2osse.so.1) 00002B570129EC83 _ZN11OSSTrapFile4dumpEmiP7siginfoPv + 0x0009 (/opt/ibm/db2/V9.5/lib64/libdb2osse.so.1) 00002B56FD80BA35 sqlo_trce + 0x03f3 (/opt/ibm/db2/V9.5/lib64/libdb2e.so.1) 00002B56FD84A45D sqloEDUCodeTrapHandler + 0x0107 (/opt/ibm/db2/V9.5/lib64/libdb2e.so.1) 00002B56FB193C00 address: 0x00002B56FB193C00 ; dladdress: 0x00002B56FB186000 ; offset in lib: 0x000000000000DC00 ; (/lib64/libpthread.so.0) 00002B56FC55FC7E _Z16sqlqgGetDjTranCBP8sqeAgent + 0x0012 (/opt/ibm/db2/V9.5/lib64/libdb2e.so.1) 00002B56FC62EC3B _Z20sqlqg_dump_ctrl_blksv + 0x0137 (/opt/ibm/db2/V9.5/lib64/libdb2e.so.1) 00002B56FD964A67 _Z20sqlqg_signal_handleri + 0x004f (/opt/ibm/db2/V9.5/lib64/libdb2e.so.1) 00002B56FC5D01CC sqloExecuteEDUExitList + 0x0136 (/opt/ibm/db2/V9.5/lib64/libdb2e.so.1) 00002B56FD84A944 sqloDumpDiagInfoHandler + 0x01d8 (/opt/ibm/db2/V9.5/lib64/libdb2e.so.1)
Local fix
If not using nicknames set FEDERATED NO.
Problem summary
**************************************************************** * USERS AFFECTED: * * Federation server. * **************************************************************** * PROBLEM DESCRIPTION: * * DB2 crash with signal 11 (SEGV) when Federated is enabled * * and dumping a specific memory. * * * * If DB2 server is running on Linux, the call stack may look * * like below: * * * * 00002B57012A3047 ossDumpStackTraceEx + 0x01f7 * * (/opt/ibm/db2/V9.5/lib64/libdb2osse.so.1) * * 00002B570129EBBC _ZN11OSSTrapFile6dumpExEmiP7siginfoPvm + * * 0x00b4 * * (/opt/ibm/db2/V9.5/lib64/libdb2osse.so.1) * * 00002B570129EC83 _ZN11OSSTrapFile4dumpEmiP7siginfoPv + * * 0x0009 * * (/opt/ibm/db2/V9.5/lib64/libdb2osse.so.1) * * 00002B56FD80BA35 sqlo_trce + 0x03f3 * * (/opt/ibm/db2/V9.5/lib64/libdb2e.so.1) * * 00002B56FD84A45D sqloEDUCodeTrapHandler + 0x0107 * * (/opt/ibm/db2/V9.5/lib64/libdb2e.so.1) * * 00002B56FB193C00 address: 0x00002B56FB193C00 ; dladdress: * * 0x00002B56FB186000 ; offset in lib: 0x000000000000DC00 ; * * (/lib64/libpthread.so.0) * * 00002B56FC55FC7E _Z16sqlqgGetDjTranCBP8sqeAgent + 0x0012 * * (/opt/ibm/db2/V9.5/lib64/libdb2e.so.1) * * 00002B56FC62EC3B _Z20sqlqg_dump_ctrl_blksv + 0x0137 * * (/opt/ibm/db2/V9.5/lib64/libdb2e.so.1) * * 00002B56FD964A67 _Z20sqlqg_signal_handleri + 0x004f * * (/opt/ibm/db2/V9.5/lib64/libdb2e.so.1) * * 00002B56FC5D01CC sqloExecuteEDUExitList + 0x0136 * * (/opt/ibm/db2/V9.5/lib64/libdb2e.so.1) * * 00002B56FD84A944 sqloDumpDiagInfoHandler + 0x01d8 * * (/opt/ibm/db2/V9.5/lib64/libdb2e.so.1) * * * * * * This trap on Linux platform may happen in below * * conditions(but not limited): * * 1) federated is enabled. * * 2) db2 dump is invoked. * * * * * * If DB2 server is running on AIX, the call stack may look * * like below: * * * * 0x000000000000F448 ?unknown + 0x0 * * 0x090000000EEA17B0 _gtraceVar + 0x370 * * 0x090000001170CBEC sqltData + 0xF4 * * 0x09000000118F303C sqltData@glue6C + 0x78 * * 0x0900000010B837BC sqlt_logerr_dump + 0x54 * * 0x0900000011F27F88 sqlqg_signal_handler__Fi + 0x21C * * 0x0900000010BEFF78 sqloExecuteEDUExitList + 0xB0 * * * * Nested signal handlers detected * * * * This trap on AIX platform may happen in below conditions(but * * not limited): * * 1) federated is enabled. * * 2) db2 dump is invoked during db2trc is on or immediately * * after db2trc off. * * * * * * Local Fix: * * Any of following workarounds can bypass the trap. * * * * - If not using nicknames, then you can set FEDERATED to NO. * * Instance recycling it needed. * * - Avoid db2 dumping. * * - If it is on AIX, you have to make sure that db2 dump does * * not happend during db2 trace is on. * **************************************************************** * RECOMMENDATION: * * Update to v91fp9 or higher fixpacks. * **************************************************************** Users affected: Users of the DB2 for LUW Homogeneous Federation Feature or InfoSphere Federation Server Problem description and summary: See error description.
Problem conclusion
Problem was first fixed in Version 9.1 FixPak 9 (s100326 ). This fix should be applied on the federation server.
Temporary fix
Any of following workarounds can bypass the trap. - If not using nicknames, then you can set FEDERATED to NO. Instance recycling it needed. - Avoid db2 dumping. - If it is on AIX, you have to make sure that db2 dump does not happend during db2 trace is on.
Comments
APAR Information
APAR number
JR35062
Reported component name
FEDERATED RUNTI
Reported component ID
5724N9703
Reported release
910
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2009-12-07
Closed date
2010-04-14
Last modified date
2011-02-24
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
FEDERATED RUNTI
Fixed component ID
5724N9703
Applicable component levels
R910 PSN
UP
R911 PSN
UP
[{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSCAVPX","label":"Federated Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
24 February 2011