In a federated server utilizing two-phase-commits and LOCK
SNAPSHOTS, it is possible for the engine to panic in SQLO_XLATCH
with a probe(in db2diag.log) indicating release conflict when
unlocking an unlatched lock.
snippet from db2diag.log:
<timestamp> LEVEL: Severe
PID : <my_pid> TID : <my_tid> PROC :
db2sysc
INSTANCE: <my_inst> NODE : <node> DB :
<db_name>
APPHDL : <app_hdl> APPID: <my_app_id>
AUTHID : <auth_id>
EDUID : <eduid> EDUNAME: <edu_name>
FUNCTION: DB2 UDB, SQO Latch Tracing,
sqlo_xlatch::releaseConflict, probe:10
DATA #1 : String, 27 bytes
unlocking an unlatched lock
DATA #2 : Pointer, 8 bytes
0x0700000171b69868
DATA #3 : String, 123 bytes
{
lock = { 0x00000000 [ unlocked ] }
identity =
SQLQG_F2PC_T::federatedProcessingSnapshotLatch (144)
}
DATA #4 : Hexdump, 8 bytes
0x0700000171B69868 : 0000 0000 0090 0000
........
CALLSTCK: (Static functions may not be resolved correctly, as
they are resolved to the nearest symbol)
[0] 0x090000000D5437D4 pdLog + 0xE0
[1] 0x090000000D95E5F0 pdLog@glue413 + 0x12C
[2] 0x090000000DB8CB60 sqloSpinLockReleaseConflict + 0x5C
[3] 0x090000000D36A248 sqloSpinLockReleaseConflict@glue73 +
0x78
[4] 0x090000000EE8F608
sqlpm_write_locks_indoubt_tran__FP16sqeLocalDatabaseP8sqeAgentP1
9sqm_snapshot_bufferUiPUiT5P16sqlm_header_info + 0x64C
[5] 0x090000000EE8DD14
@92@sqm_snap_db_locks__FPC16sqm_agent_entityRC8sqlo_gmtP19sqm_sn
apshot_bufferP16sqeLocalDatabaseP14sqlm_collectedPCcCUiPP15sqlm
+ 0x564
[6] 0x090000000CD006D0
sqlmonssagnt__FUi13sqm_entity_idP6sqlmaiT1PvP14sqlm_collectedUsT
7P5sqlca + 0xD2C
[7] 0x090000000D922EBC sqlmonssbackend__FP12SQLE_DB2RA_T +
0x228
[8] 0x090000000DBDD12C sqlesrvr__FP14db2UCinterface + 0x738
[9] 0x090000000D351B68 sqleMappingFnServer__FP5sqldaP5sqlca +
0x1D0
The stack would look similar to this:
<StackTrace>
-------Frame------ ------Function + Offset------
0x090000000066CF54 pthread_kill + 0xD4
0x090000000CD0B4E4 sqloDumpEDU + 0x54
0x090000000CB9B448 sqle_panic__Fv + 0xBC
0x090000000DF49B50 sqle_panic__Fv@glue198 + 0x7C
0x090000000DB8CB68 sqloSpinLockReleaseConflict + 0x64
0x090000000D36A248 sqloSpinLockReleaseConflict@glue73 + 0x78
0x090000000EE8F608
sqlpm_write_locks_indoubt_tran__FP16sqeLocalDatabaseP8sqeAgentP1
9sqm_snapshot_bufferUiPUiT5P16sqlm_header_info + 0x64C
0x090000000EE8DD14
@92@sqm_snap_db_locks__FPC16sqm_agent_entityRC8sqlo_gmtP19sqm_sn
apshot_bufferP16sqeLocalDatabaseP14sqlm_collectedPCcCUiPP15sqlm_
dbase_lockP16sqlm_header_info + 0x564
0x090000000CD006D0
sqlmonssagnt__FUi13sqm_entity_idP6sqlmaiT1PvP14sqlm_collectedUsT
7P5sqlca + 0xD2C
0x090000000D922EBC sqlmonssbackend__FP12SQLE_DB2RA_T + 0x228
0x090000000DBDD12C sqlesrvr__FP14db2UCinterface + 0x738
0x090000000D351B68 sqleMappingFnServer__FP5sqldaP5sqlca + 0x1D0
0x090000000D351470
sqlerKnownProcedure__FiPcPiP5sqldaT4P13sqlerFmpTableP8sqeAgentP5
sqlca + 0x344
0x090000000D3503A8 sqlerCallDL__FP14db2UCinterfaceP9UCstpInfo +
0x580
0x090000000D350980
.sqljs_ddm_excsqlstt.fdpr.clone.253__FP14db2UCinterfaceP13sqljDD
MObject + 0xE4
0x090000000D50E55C
sqljsParseRdbAccessed__FP13sqljsDrdaAsCbP13sqljDDMObjectP14db2UC
interface + 0x110
0x090000000D50E204
.sqljsParse.fdpr.clone.234__FP13sqljsDrdaAsCbP14db2UCinterfaceP8
sqeAgentb + 0x6D8
0x090000000D511984 @63@sqljsSqlam__FP14db2UCinterfaceP8sqeAgentb
+ 0x2C0
0x090000000D667148
@63@sqljsDriveRequests__FP8sqeAgentP14db2UCconHandle + 0xB4
0x090000000D666E38
@63@sqljsDrdaAsInnerDriver__FP18SQLCC_INITSTRUCT_Tb + 0x2D4
0x090000000D6668BC sqljsDrdaAsDriver__FP18SQLCC_INITSTRUCT_T +
0xFC
0x090000000D2E5A3C RunEDU__8sqeAgentFv + 0x280
0x090000000D2E0EA8 EDUDriver__9sqzEDUObjFv + 0xDC
0x090000000D30DAEC sqloEDUEntry + 0x254
</StackTrace> |
