A fix is available
APAR status
Closed as program error.
Error description
Users effected: Linux / DB2 users Problem description: db2agent hangs. Stack of agent shows it's waiting in: #0 0x0000002a9844debb in __lll_mutex_lock_wait () from /lib64/tls/libc.so.6 #1 0x0000007fbffb6350 in ?? () #2 0x0000000045338ff4 in ?? () #3 0x0000002a9840ae9e in __tzname_max () from /lib64/tls/libc.so.6 #4 0x0000002a972d067c in SQLCC_FFDC_TQM_LISTEN () from /db2/home/db2inst1/sqllib/lib/libdb2e.so.1 #5 0x0000002a9566b1c0 in __stack_prot () from /lib64/ld-linux-x86-64.so.2 #6 0x52534f3c0a3e6e6f in ?? () #7 0x54656372756f7365 in ?? () ... #25 0x0000002a984093de in gmtime_r () from /lib64/tls/libc.so.6 #26 0x0000002a9714008b in sqlo_trce () from /db2/home/db2inst1/sqllib/lib/libdb2e.so.1 This only happens when customer tries to keep dumping out call stack of the db2 agent that's currently getting timestamp from Linux OS. db2 agent while in the process of getting current timestamp, acquires some resource protected by the mutex and then, while holding it, does receive a signal to dump the stack trace (SIGURG). It invokes the signal handler and, from sqlo_trce(), DB2 try to obtain current timestamp again, since mutex is still acquired by the previous get time attempt, db2 agent wait indefinitely, deadlocking itself.
Local fix
Problem summary
ERROR DESCRIPTION: Users effected: Linux / DB2 users Problem description: db2agent hangs. Stack of agent shows it's waiting in: #0 0x0000002a9844debb in __lll_mutex_lock_wait () from /lib64/tls/libc.so.6 #1 0x0000007fbffb6350 in ?? () #2 0x0000000045338ff4 in ?? () #3 0x0000002a9840ae9e in __tzname_max () from /lib64/tls/libc.so.6 #4 0x0000002a972d067c in SQLCC_FFDC_TQM_LISTEN () from /db2/home/db2inst1/sqllib/lib/libdb2e.so.1 #5 0x0000002a9566b1c0 in __stack_prot () from /lib64/ld-linux-x86-64.so.2 #6 0x52534f3c0a3e6e6f in ?? () #7 0x54656372756f7365 in ?? () ... #25 0x0000002a984093de in gmtime_r () from /lib64/tls/libc.so.6 #26 0x0000002a9714008b in sqlo_trce () from /db2/home/db2inst1/sqllib/lib/libdb2e.so.1 This only happens when customer tries to keep dumping out call stack of the db2 agent that's currently getting timestamp from Linux OS. db2 agent while in the process of getting current timestamp, acquires some resource protected by the mutex and then, while holding it, does receive a signal to dump the stack trace (SIGURG). It invokes the signal handler and, from sqlo_trce(), DB2 try to obtain current timestamp again, since mutex is still acquired by the previous get time attempt, db2 agent wait indefinitely, deadlocking itself.
Problem conclusion
First fixed in DB2 UDB Version 8.2, FixPak 16, s080111
Temporary fix
Comments
APAR Information
APAR number
LI71787
Reported component name
DB2 UDB WSE LIN
Reported component ID
5765F3504
Reported release
810
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2006-12-06
Closed date
2008-02-05
Last modified date
2008-02-05
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
DB2 UDB WSE LIN
Fixed component ID
5765F3504
Applicable component levels
R820 PSY
UP
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"DB2 for Linux- UNIX and Windows"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"810","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Document Information
Modified date:
16 October 2021