IBM Support

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

Subscribe

You can track all active APARs for this component.

 

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

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * none                                                         *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * DB2 AGENT HANGS WHEN USER GENERATES CALL STACK ON AN AGENT   *
    *                                                              *
    * THAT'S RUNNING LOCALTIME_R() TO GET TIMESTAMP ON LINUX       *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * None.                                                        *
    ****************************************************************
    

Problem conclusion

  • 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
    

Temporary fix

Comments

APAR Information

  • APAR number

    LI73602

  • Reported component name

    DB2 UDB WSE LIN

  • Reported component ID

    5765F3504

  • Reported release

    950

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2008-07-23

  • Closed date

    2010-03-01

  • Last modified date

    2010-03-01

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

    LI71787

  • 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

  • R950 PSN

       UP

[{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSEPGG","label":"DB2 for Linux, UNIX and Windows"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"950","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
01 March 2010