Fixes are available
DB2 Version 9.1 Fix Pack 7 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 7a for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 8 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 9 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 10 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 11 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 12 for Linux, UNIX and Windows
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 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: 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 conclusion
The complete fix for this problem first appears in DB2 UDB Version 9.1 FixPak 7.
Temporary fix
n/a
Comments
APAR Information
APAR number
IZ39280
Reported component name
DB2 UDB ESE SOL
Reported component ID
5765F4102
Reported release
910
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2008-12-04
Closed date
2009-04-16
Last modified date
2009-04-16
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 ESE SOL
Fixed component ID
5765F4102
Applicable component levels
R810 PSN
UP
R820 PSN
UP
R910 PSN
UP
R950 PSN
UP
[{"Line of Business":{"code":"LOB10","label":"Data and AI"},"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":"910"}]
Document Information
Modified date:
04 October 2021