IBM Support

IZ39279: MULTI-THREADED APPLICATIONS CAN SEGV IN SQLNLSAPPLL

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Using a multi-threaded application againts DB2 UDB can lead to
    a SEGV (signal 11) in sqlnlsAppLL or other sqlnls* functions.
    
    Here is a possible stack:
    
    =>[1] __lwp_kill(0x0, 0x6, 0x0, 0xffffffff7f2f5ec0,
    0xffffffff63d09200, 0x5), at 0xffffffff7f1d34c0
      [2] raise(0x6, 0x0, 0x100986ee8, 0xffffffffffffffff,
    0xffffffff7f2ea000, 0x0), at 0xffffffff7f170b24
      [3] abort(0x1, 0x1b8, 0x1001f2ca4, 0x19fb60, 0x0, 0x0), at
    0xffffffff7f14a5ac
      [4] fatalSignalHandler(0xb, 0x0, 0x100909800, 0x1009094c0,
    0x100909a30, 0x0), at 0x1001401f8
      [5] __sighndlr(0xb, 0xffffffff46ff9e20, 0xffffffff46ff9b40,
    0x1001400fc, 0x0, 0xa), at 0xffffffff7f1d23c4
      ---- called from signal handler with signal 11 (SIGSEGV)
    ------
      [6] sqlnlsAddLL(0x40, 0x0, 0x1010dbfe8, 0x1010dbfe8,
    0x1010dbfe8, 0x0), at 0xffffffff66e30d38
      [7] sqlnlsSearchConv(0x4b8, 0x333, 0x1, 0xffffffff46ffaa50,
    0x19b80000, 0x333), at 0xffffffff66e3135c
      [8] sqlnlsFindConv(0x4b8, 0xffffffff46ffa2a8,
    0xffffffff46ffa2ab, 0xffffffff46ffaa50, 0x20, 0x0), at
    0xffffffff66e31534
      [9] sqlnls_valtab(0x0, 0x0, 0x0, 0xffffffff46ffa488,
    0xffffffff46ffa478, 0xffffffff46ffaa50), at 0xffffffff66e2f910
      [10] sqlnlscpcv_noUTF(0x0, 0xffffffff46ffaa50, 0x870f0000,
    0x34b0, 0x20, 0x333), at 0xffffffff66e2b978
      [11] sqlnlsCodePageConvert(0xffffffff46ffa9f8,
    0xffffffff46ffaa50, 0x4b8, 0x4400, 0x3400, 0xffffffff46ffa9d8),
    at 0xffffffff66e32504
      [12] sqlnlscpcv(0xffffffff46ffa9e8, 0x0, 0x1043939ce, 0x46,
    0x0, 0xffffffff46ffa9d8), at 0xffffffff66e2af20
      [13] sqlnlscpca(0x1043939bc, 0x46, 0x333, 0x8000, 0x0,
    0xffffffff67bc5498), at 0xffffffff6768dca8
      [14] sqljrCodePageConvertSqlca(0x1043a05f0, 0x1043939bc,
    0x333, 0x4b8, 0xffffffff67a1a788, 0x4b8), at 0xffffffff677a5ff0
      [15] sqljrParseSqlcaGrp(0x1043a05f0, 0x1043dc0d7, 0x1043939bc,
    0x1043a1680, 0x19b80000, 0xffffffff67bc52d8), at
    0xffffffff677a5dcc
      [16] sqljrParseSqldard(0x1043a05f0, 0x0, 0x3, 0x0,
    0x1043a1680, 0xffffffff67bc52d8), at 0xffffffff67767a94
      [17] sqljrParseDescribePrepareReply(0x1043a05f0, 0x2213,
    0x2411, 0x2000, 0xa, 0xffffffff67747108), at 0xffffffff677472a8
      [18] sqljrParse(0x1043a05f0, 0x0, 0x1043a1ce0,
    0xffffffff67a1a788, 0x1043a1680, 0xffffffff67bf4748), at
    0xffffffff677a49f4
      [19] sqljrDrdaArOpen(0x1043a05f0, 0x0, 0x0, 0x1043a1680, 0x0,
    0x0), at 0xffffffff6776f1ec
      [20] csmOpen(0x1043a05f0, 0x1043b98e8, 0x0, 0x1043a05f0, 0x0,
    0x8), at 0xffffffff677af748
      [21] CLI_sqlOpen(0x1043b93e0, 0x1043b93f0, 0x1043b98e8, 0x3,
    0x0, 0x0), at 0xffffffff674d0404
      [22] SQLExecute2(0x1043b93e0, 0x1043b93f0, 0x0,
    0xffffffffffffffff, 0x1043939bc, 0x0), at 0xffffffff6745d67c
      [23] SQLExecute(0x0, 0x0, 0x0, 0xffffffff67a1a788, 0x0,
    0xffffffffffffffff), at 0xffffffff67455f9c
    
    This problem is already fixed in V9.5.
    
    This problem does not occur on Windows.
    

Local fix

  • n/a
    

Problem summary

  • USERS AFFECTED: All using Db2 UDB on Windows.
    
    PROBLEM DESCRIPTION:
    
                          Using a multi-threaded application againts
    DB2 UDB can lead to
    a SEGV (signal 11) in sqlnlsAppLL or other sqlnls* functions.
    
    Here is a possible stack:
    
    =>[1] __lwp_kill(0x0, 0x6, 0x0, 0xffffffff7f2f5ec0,
    0xffffffff63d09200, 0x5), at 0xffffffff7f1d34c0
      [2] raise(0x6, 0x0, 0x100986ee8, 0xffffffffffffffff,
    0xffffffff7f2ea000, 0x0), at 0xffffffff7f170b24
      [3] abort(0x1, 0x1b8, 0x1001f2ca4, 0x19fb60, 0x0, 0x0), at
    0xffffffff7f14a5ac
      [4] fatalSignalHandler(0xb, 0x0, 0x100909800, 0x1009094c0,
    0x100909a30, 0x0), at 0x1001401f8
      [5] __sighndlr(0xb, 0xffffffff46ff9e20, 0xffffffff46ff9b40,
    0x1001400fc, 0x0, 0xa), at 0xffffffff7f1d23c4
      ---- called from signal handler with signal 11 (SIGSEGV)
    ------
      [6] sqlnlsAddLL(0x40, 0x0, 0x1010dbfe8, 0x1010dbfe8,
    0x1010dbfe8, 0x0), at 0xffffffff66e30d38
      [7] sqlnlsSearchConv(0x4b8, 0x333, 0x1, 0xffffffff46ffaa50,
    0x19b80000, 0x333), at 0xffffffff66e3135c
      [8] sqlnlsFindConv(0x4b8, 0xffffffff46ffa2a8,
    0xffffffff46ffa2ab, 0xffffffff46ffaa50, 0x20, 0x0), at
    0xffffffff66e31534
      [9] sqlnls_valtab(0x0, 0x0, 0x0, 0xffffffff46ffa488,
    0xffffffff46ffa478, 0xffffffff46ffaa50), at 0xffffffff66e2f910
      [10] sqlnlscpcv_noUTF(0x0, 0xffffffff46ffaa50, 0x870f0000,
    0x34b0, 0x20, 0x333), at 0xffffffff66e2b978
      [11] sqlnlsCodePageConvert(0xffffffff46ffa9f8,
    0xffffffff46ffaa50, 0x4b8, 0x4400, 0x3400, 0xffffffff46ffa9d8),
    at 0xffffffff66e32504
      [12] sqlnlscpcv(0xffffffff46ffa9e8, 0x0, 0x1043939ce, 0x46,
    0x0, 0xffffffff46ffa9d8), at 0xffffffff66e2af20
      [13] sqlnlscpca(0x1043939bc, 0x46, 0x333, 0x8000, 0x0,
    0xffffffff67bc5498), at 0xffffffff6768dca8
      [14] sqljrCodePageConvertSqlca(0x1043a05f0, 0x1043939bc,
    0x333, 0x4b8, 0xffffffff67a1a788, 0x4b8), at 0xffffffff677a5ff0
      [15] sqljrParseSqlcaGrp(0x1043a05f0, 0x1043dc0d7, 0x1043939bc,
    0x1043a1680, 0x19b80000, 0xffffffff67bc52d8), at
    0xffffffff677a5dcc
      [16] sqljrParseSqldard(0x1043a05f0, 0x0, 0x3, 0x0,
    0x1043a1680, 0xffffffff67bc52d8), at 0xffffffff67767a94
      [17] sqljrParseDescribePrepareReply(0x1043a05f0, 0x2213,
    0x2411, 0x2000, 0xa, 0xffffffff67747108), at 0xffffffff677472a8
      [18] sqljrParse(0x1043a05f0, 0x0, 0x1043a1ce0,
    0xffffffff67a1a788, 0x1043a1680, 0xffffffff67bf4748), at
    0xffffffff677a49f4
      [19] sqljrDrdaArOpen(0x1043a05f0, 0x0, 0x0, 0x1043a1680, 0x0,
    0x0), at 0xffffffff6776f1ec
      [20] csmOpen(0x1043a05f0, 0x1043b98e8, 0x0, 0x1043a05f0, 0x0,
    0x8), at 0xffffffff677af748
      [21] CLI_sqlOpen(0x1043b93e0, 0x1043b93f0, 0x1043b98e8, 0x3,
    0x0, 0x0), at 0xffffffff674d0404
      [22] SQLExecute2(0x1043b93e0, 0x1043b93f0, 0x0,
    0xffffffffffffffff, 0x1043939bc, 0x0), at 0xffffffff6745d67c
      [23] SQLExecute(0x0, 0x0, 0x0, 0xffffffff67a1a788, 0x0,
    0xffffffffffffffff), at 0xffffffff67455f9c
    
    This problem is already fixed in V9.5.
    
    This problem does not occur on Windows.
    
    PROBLEM SUMMARY:
    
    see problem description.
    

Problem conclusion

  • The complete fix for this problem first appears in DB2 UDB
    Version 8.1 FixPak 18.
    

Temporary fix

Comments

APAR Information

  • APAR number

    IZ39279

  • Reported component name

    DB2 UDB ESE SOL

  • Reported component ID

    5765F4102

  • Reported release

    810

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2008-12-04

  • Closed date

    2009-09-11

  • Last modified date

    2009-09-11

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

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

    IZ39280

Fix information

  • Fixed component name

    DB2 UDB ESE SOL

  • Fixed component ID

    5765F4102

Applicable component levels

  • R810 PSN

       UP

  • R820 PSN

       UP

  • R910 PSN

       UP

  • R950 PSN

       UP

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"810","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
11 September 2009