LI71787: DB2 AGENT HANGS WHEN USER GENERATES CALL STACK ON AN AGENT THAT'S RUNNING LOCALTIME_R() TO GET TIMESTAMP ON LINUX

DB2 UDB Version 8.1 FixPak 16 (also known as Version 8.2 FixPak 9 )

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 is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  IZ28037 LI73602

Fix information

• Fixed component name

  DB2 UDB WSE LIN

• Fixed component ID

  5765F3504

Applicable component levels

• R820 PSY

     UP