DB2 FOR LUW / DB2FORLUW / 970 - DB2

DB2 can crash with the following stack: 
 
0        ossHexDumpLine 
1        ossHexDumpToBuffer 
2        pdHexDump 
3        pdFormatArg 
4        pdInvokeFmtFnc 
5        formatPDType 
6        pdTypeFormatOrDump 
7        pdLogInternal 
8        pdLog 
9        sqlra_get_section 
 
10       sqlrr_sql_request_pre 
11       sqlrr_prepare 
12       sqljs_ddm_prpsqlstt 
13       sqljsParseRdbAccessed 
14       sqljsParse 
15       sqljsSqlam 
16       sqljsDriveRequests 
17       sqljsDrdaAsInnerDriver 
18       sqljsDrdaAsDriver 
19       sqeAgent::RunEDU 
20       sqlzRunEDU 
21       sqloEDUEntry 
 
The last message before the crash in the db2diag.log is on 
sqlragsn, probe 1350 
 
FUNCTION: DB2 UDB, access plan manager, sqlra_get_section, 
probe:1350 
MESSAGE : cannot prepare a non-dynamic section for section 14. 
DATA #1 : Hexdump, 8 bytes 
0xFFFFFFFF643B3E58 : 4E55 4C4C 4944 2020 
NULLID 
 
There is no message in the db2diag.log after this with sqlragsn, 
probe 1400 for the same EDUID. 
 
If we did not crash we would have after the message above: 
 
FUNCTION: DB2 UDB, access plan manager, sqlra_get_section, 
probe:1400 
MESSAGE : cannot prepare a non-dynamic section for section 14. 
DATA #1 : Hexdump, 128 bytes 
0xFFFFFFFF611AFFBC : 5351 4C55 4648 3133 2020 2020 2020 2020 
SQLUFH13 
0xFFFFFFFF611AFFCC : 2020 4141 4141 4159 4758 000E FFFF FFFF 
 AAAAAYGX...... 
 
Note the Hexdump might vary. 
 
We will only hit this crash as a result of hitting -804 
(SQL0804N), reason code 100. 
 
DB2 Version 9.5 will show sqlragsn  function instead

**************************************************************** 
* USERS AFFECTED:                                              * 
* ALL                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* We are hitting a memory boundary with the package name that  * 
* we are trying to print.                                      * 
*                                                              * 
* Signal #11 (SIGSEGV): si_addr is 0xFFFFFFFF63B00000, si_code * 
* is 0x00000001 (SEGV_MAPERR:Address not mapped to object.)    * 
*                                                              * 
* The trap file will show for the address that we are failing  * 
* on that it is a memory boundary:                             * 
* <ProcessObjects>                                             * 
* 0xffffffff63a00000-0xffffffff63b00000      1024K rw--  [     * 
* anon ]                                                       * 
*                                                              * 
* This is a rare condition. The problem is due to not passing  * 
* the package name length to the function sqlra_get_section    * 
* and using a standard size to print the package name.         * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 Version 9.7 and Fix Pack 5                    * 
****************************************************************

DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
 

Problem was first fixed in DB2 Version 9.7 and Fix Pack 5

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

31.03.2011
10.12.2011
10.12.2011

9.7.