When using a series of SQL routines that use Arrays as
parameters, the DB2 instance can crash (either produce
sustainable traps, or panics and comes down). When it 'traps'
it can generate a call stack as follows;
<StackTrace>
-------Frame------ ------Function + Offset------
0x090000000BAF8B18
cloneDyn__20sqlriArrayDescriptorFP8sqlrr_cbP20sqlriArrayDescript
or + 0x1D0
0x090000000A81F520
copy__20sqlriArrayDescriptorFP8sqlrr_cbP20sqlriArrayDescriptorb
+ 0x660
0x090000000CA2ECBC sqlrxArrayCopy__FP8sqeAgentP10sqlz_valueT2b +
0x198
0x090000000C9AD304
sqlriRowDescCopy__FP8sqlrr_cbP18sqlriRowDescriptorT2 + 0x16C
0x090000000CA2EF30 sqlvSqlPLCopyRow__FP8sqlrr_cbP10sqlz_valueT2
+ 0x1D8
0x090000000C69FDA8 copyData__3PVMFP10sqlz_valueT1Ulb + 0x38
0x090000000C675218 copyVariable__3PVMFUiT1 + 0xB0
0x090000000C6737B0 run__3PVMFv + 0xD44
0x090000000C670F90 pvm_entry + 0x460
0x090000000AF8907C sqloInvokeFnArgs + 0xDC
0x090000000B1BB678 sqloInvokeFnArgs@glue4D6 + 0x78
0x090000000B0F2ED4
sqlriInvokerTrusted__FP10sqlri_ufobP21sqlriRoutineErrorIntfb +
0x1E0
0x090000000AF86620 sqlriInvokeInvoker__FP10sqlri_ufobb + 0xD8
0x090000000A7C0C00 sqlricall__FP8sqlrr_cb + 0x598
0x090000000AEDBFA4 sqlriSectInvoke__FP8sqlrr_cbP12sqlri_opparm +
0x24
0x090000000AF2E7E4 sqlrr_process_execute_request__FP8sqlrr_cbib
+ 0xC40
0x090000000AF44728
.sqlrr_execute.fdpr.clone.1958__FP14db2UCinterfaceP9UCstpInfo +
0xB4
0x090000000AF450D0
.sqljs_ddm_excsqlstt.fdpr.clone.253__FP14db2UCinterfaceP13sqljDD
MObject + 0x658
0x090000000AF4655C
sqljsParseRdbAccessed__FP13sqljsDrdaAsCbP13sqljDDMObjectP14db2UC
interface + 0x110
0x090000000B03EE70
.sqljsParse.fdpr.clone.234__FP13sqljsDrdaAsCbP14db2UCinterfaceP8
sqeAgentb + 0xEC
0x090000000AF49984 @63@sqljsSqlam__FP14db2UCinterfaceP8sqeAgentb
+ 0x2C0
0x090000000B09F148
@63@sqljsDriveRequests__FP8sqeAgentP14db2UCconHandle + 0xB4
0x090000000B09EE38
@63@sqljsDrdaAsInnerDriver__FP18SQLCC_INITSTRUCT_Tb + 0x2D4
0x090000000B09E8BC sqljsDrdaAsDriver__FP18SQLCC_INITSTRUCT_T +
0xFC
0x090000000AD1DA3C RunEDU__8sqeAgentFv + 0x280
0x090000000AD18EA8 EDUDriver__9sqzEDUObjFv + 0xDC
0x090000000AD45AEC sqloEDUEntry + 0x254
</StackTrace>
When DB2 panics it can produce an entry as follows in the
db2diag.log:
2014-01-11-21.06.15.308628+060 E214845A1441 LEVEL: Severe
PID : 4325778 TID : 5398 PROC : db2sysc
0
INSTANCE: db2inst1 NODE : 000 DB : SAMPLE
APPHDL : 0-31 APPID:
127.0.0.1.44131.260133143517
AUTHID : DB2USER
EDUID : 5398 EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, SQO Memory Management,
sqloDiagnoseFreeBlockFailure, probe:999
MESSAGE : Memory validation failure, diagnostic file dumped.
DATA #1 : String, 28 bytes
Corrupt pool free tree node.
DATA #2 : File name, 32 bytes
4325778.5398.mem_diagnostics.txt
CALLSTCK: (Static functions may not be resolved correctly, as
they are resolved to the nearest symbol)
[0] 0x090000000AF7B7D4 pdLog + 0xE0
[1] 0x090000000BAD2DB0
diagnoseMemoryCorruptionAndCrash__13SQLO_MEM_POOLFUlCPCcCb +
0x2AC
[2] 0x090000000BAD2A2C
diagnoseMemoryCorruptionAndCrash__13SQLO_MEM_POOLFUlCPCcCb@glue8
07 + 0x7C
[3] 0x090000000AE15A40
.allocateMemoryBlock.fdpr.clone.242__13SQLO_MEM_POOLFCUlUlT1UiT1
PPvPP17SqloChunkSubgroupPP12SMemLostNodeCP12SMemLogEvent + 0xC
[4] 0x0000000000000000 ?unknown + 0x0
[5] 0x090000000AE16F1C sqlogmblkEx + 0x770
[6] 0x090000000F5C92E8 sqlogmblkEx + 0x24C
[7] 0xFFFFFFFFFFFFFFFC ?unknown + 0xFFFFFFFF
[8] 0x090000000C6A54B4
buildNestedArrayZVal__11pvmVarTableCFUisP10sqlz_value + 0x37C
[9] 0x090000000C6A4948
buildNestedRowZVal__11pvmVarTableCFUisP10sqlz_valueb + 0x904
The problem is more likely to occur when the following
conditions are met:
- An SQL routine is declared with one or more array parameters,
whose element type is either a row type containing at least one
array-typed field, or the element type is another array type.
- The routine modifies one or more elements of these parameters
in its body.
- The routine is called more than once.
The presence of these conditions does not guarantee that the DB2
instance will crash or produce trap files. |
