|
Problem IC63619
|
Status: Closed |
DB2 AGENT HANGS WHEN USER GENERATES CALL STACK ON AN AGENT THAT'S RUNNING LOCALTIME_R() TO GET TIMESTAMP ON LINUX |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem 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 Summary: |
****************************************************************
* USERS AFFECTED: *
* unknown *
****************************************************************
* PROBLEM DESCRIPTION: *
* DB2 AGENT HANGS WHEN USER GENERATES CALL STACK ON AN AGENT *
* *
* THAT'S RUNNING LOCALTIME_R() TO GET TIMESTAMP ON LINUX *
****************************************************************
* RECOMMENDATION: *
* n/a *
**************************************************************** |
| Local Fix: |
|
| available fix packs: |
DB2 Version 9.7 Fix Pack 1 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
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 9a 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 10 for Linux, UNIX, and Windows
|
| Solution |
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:
none |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 08.10.2009
01.03.2010
01.03.2010 |
| Problem solved at the following versions (IBM BugInfos) |
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.1
|
 |
