IBM Support

IC75339: INSTANCE CRASH IN DPF ENVIRONMENT IF THERE IS A WRONG OFFSET INPUT TO METHOD L WHILE DOING A DB2 LOAD WITH ASC SOURCE FILE.

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • Regarding DB2 Load operation, one option of load "MODIFIED BY"
    with "METHOD L", specifies the start and end column numbers from
    which to load data. A column number is a byte offset from the
    beginning of a row of data. It is numbered starting from 1. This
    method can only be used with ASC files, and is the only valid
    method for that file type.
    
    In this load command's METHOD L (beginloc endloc), the offset of
    endloc must be greater or equal to beginloc otherwise the load
    operation will be failing gracefully with thus certain invalid
    input.
    
    But in a DPF environment, if there is a invalid input of METHOD
    L (The endloc is less than beginloc) to the column that is part
    of the table's distribution key, the load operation will cause
    the instance crash. Because the load db2lpart EDU (load
    partitioning SA) is handed a string with "negative length", and
    DB2 are missing code that check for this matter.
    
    As db2diag.log reported:
    
    2011-01-12-19.32.02.412374-300 I182007E1756        LEVEL: Severe
    PID     : 7133                 TID  : 183274301792 PROC :
    db2sysc 1
    INSTANCE: myname               NODE : 001          DB   :
    V95MPP2
    APPHDL  : 0-79                 APPID: *N0.myname.110113003126
    AUTHID  : MYNAME
    EDUID   : 117                  EDUNAME: db2lpart 1
    FUNCTION: DB2 UDB, SQO Memory Management,
    sqloDiagnoseFreeBlockFailure, probe:10
    MESSAGE : Possible memory corruption detected.
    DATA #1 : ZRC, PD_TYPE_ZRC, 4 bytes
    0x820F0002
    DATA #2 : Corrupt block address, PD_TYPE_CORRUPT_BLK_PTR, 8
    bytes
    0x0000002ac4d94000
    DATA #3 : Block header, PD_TYPE_BLK_HEADER, 24 bytes
    0x0000002AC4D93FE8 : 0000 0000 0000 0000 0000 0000 0000 0000
    ................
    0x0000002AC4D93FF8 : 0000 0000 0000 0000
    ........
    DATA #4 : Data header, PD_TYPE_BLK_DATA_HEAD, 48 bytes
    0x0000002AC4D94000 : 0000 0000 0000 0000 A040 D9C4 2A00 0000
    .........@..*...
    0x0000002AC4D94010 : 0000 0000 0000 0000 0000 0000 0000 0000
    ................
    0x0000002AC4D94020 : 0000 0000 0000 0000 8B4D AC02 0000 B0FA
    .........M......
    CALLSTCK:
      [0] 0x0000002A9684EA93 pdLog + 0xD7
      [1] 0x0000002A97ED8C0D
    /view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1 +
    0x2756C0D
      [2] 0x0000002A98A7C4A5 sqlofmblkEx + 0x8B9
      [3] 0x0000002A968387EC _Z9sqlofmblkPv + 0x6
      [4] 0x0000002A96DD8DB1 _ZN13sqluCLinkList8bCleanUpEv + 0x1F
      [5] 0x0000002A985715B4 _ZN17sqluCSerializable11iDeallocateEv +
    0x140
      [6] 0x0000002A987C273A
    _ZN27sqlusCPartRequestDescriptor11iDeallocateEv + 0x6
      [7] 0x0000002A987C65F1 _ZN18sqlusCPartSubAgent8iCleanUpEv +
    0x3C1
      [8] 0x0000002A987DAD4A _Z19sqlusSubAgentRouterP8sqeAgenti +
    0x28E
      [9] 0x0000002A973310E0 _Z20sqleSubRequestRouterP8sqeAgentPjS1_
    + 0x324
    
    2011-01-12-19.32.02.421800-300 E183764E953         LEVEL:
    Critical
    PID     : 7133                 TID  : 183274301792 PROC :
    db2sysc 1
    INSTANCE: myname               NODE : 001          DB   :
    V95MPP2
    APPHDL  : 0-79                 APPID: *N0.myname.110113003126
    AUTHID  : MYNAME
    EDUID   : 117                  EDUNAME: db2lpart 1
    FUNCTION: DB2 UDB, SQO Memory Management,
    sqloDiagnoseFreeBlockFailure, probe:10
    MESSAGE : ADM14001C  An unexpected and critical error has
    occurred: "Panic".
              The instance may have been shutdown as a result.
    "Automatic" FODC
              (First Occurrence Data Capture) has been invoked and
    diagnostic
              information has been recorded in directory
    
    "/home/hotel20/myname/sqllib/db2dump/FODC_Panic_2011-01-12-19.32
    .02.4
              21661/". Please look in this directory for detailed
    evidence about
              what happened and contact IBM support if necessary to
    diagnose the
              problem.
    
    2011-01-12-19.32.02.429430-300 E184718E1269        LEVEL: Severe
    PID     : 7133                 TID  : 183274301792 PROC :
    db2sysc 1
    INSTANCE: myname               NODE : 001          DB   :
    V95MPP2
    APPHDL  : 0-79                 APPID: *N0.myname.110113003126
    AUTHID  : MYNAME
    EDUID   : 117                  EDUNAME: db2lpart 1
    FUNCTION: DB2 UDB, SQO Memory Management,
    sqloDiagnoseFreeBlockFailure, probe:999
    MESSAGE : Memory validation failure, diagnostic file dumped.
    DATA #1 : String, 21 bytes
    Invalid block header.
    DATA #2 : File name, 37 bytes
    7133.183274301792.mem_diagnostics.txt
    CALLSTCK:
      [0] 0x0000002A9684EA93 pdLog + 0xD7
      [1] 0x0000002A97EDE3EA
    _ZN13SQLO_MEM_POOL32diagnoseMemoryCorruptionAndCrashEmPKc +
    0x200
      [2] 0x0000002A97ED8E62
    /view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1 +
    0x2756E62
      [3] 0x0000002A98A7C4A5 sqlofmblkEx + 0x8B9
      [4] 0x0000002A968387EC _Z9sqlofmblkPv + 0x6
      [5] 0x0000002A96DD8DB1 _ZN13sqluCLinkList8bCleanUpEv + 0x1F
      [6] 0x0000002A985715B4 _ZN17sqluCSerializable11iDeallocateEv +
    0x140
      [7] 0x0000002A987C273A
    _ZN27sqlusCPartRequestDescriptor11iDeallocateEv + 0x6
      [8] 0x0000002A987C65F1 _ZN18sqlusCPartSubAgent8iCleanUpEv +
    0x3C1
      [9] 0x0000002A987DAD4A _Z19sqlusSubAgentRouterP8sqeAgenti +
    0x28E
    
    2011-01-12-19.32.02.469188-300 I185988E553         LEVEL: Error
    PID     : 7133                 TID  : 183274301792 PROC :
    db2sysc 1
    INSTANCE: myname               NODE : 001          DB   :
    V95MPP2
    APPHDL  : 0-79                 APPID: *N0.myname.110113003126
    AUTHID  : MYNAME
    EDUID   : 117                  EDUNAME: db2lpart 1
    FUNCTION: DB2 UDB, base sys utilities, sqleagnt_sigsegvh,
    probe:1
    MESSAGE : Error in agent servicing application with coor_node:
    DATA #1 : Hexdump, 2 bytes
    0x0000002AABC0FA32 : 0000
    ..
    
    ...
    
    and the associated stack trace reported:
    
    <StackTrace>
    -----FUNC-ADDR---- ------FUNCTION + OFFSET------
    0x0000002A9BB4C0E7 ossDumpStackTraceEx + 0x01f7
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2osse.so.
    1)
    0x0000002A9BB47BBA _ZN11OSSTrapFile6dumpExEmiP7siginfoPvm +
    0x00b4
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2osse.so.
    1)
    0x0000002A9BB47C81 _ZN11OSSTrapFile4dumpEmiP7siginfoPv + 0x0009
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2osse.so.
    1)
    0x0000002A97EA3C19 sqlo_trce + 0x0425
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A97EE5D24 sqloEDUCodeTrapHandler + 0x0138
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A95679260 address: 0x0000002A95679260 ; dladdress:
    0x0000002A9566D000 ; offset in lib: 0x000000000000C260 ;
                    (/lib64/tls/libpthread.so.0)
    0x0000002A97ED8A66 sqloCrashOnCriticalMemoryValidationFailure +
    0x001a
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A97EDE3EF
    _ZN13SQLO_MEM_POOL32diagnoseMemoryCorruptionAndCrashEmPKc +
    0x0205
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A97ED8E62 address: 0x0000002A97ED8E62 ; dladdress:
    0x0000002A95782000 ; offset in lib: 0x0000000002756E62 ;
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A98A7C4A5 sqlofmblkEx + 0x08b9
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A968387EC _Z9sqlofmblkPv + 0x0006
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A96DD8DB1 _ZN13sqluCLinkList8bCleanUpEv + 0x001f
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A985715B4 _ZN17sqluCSerializable11iDeallocateEv +
    0x0140
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A987C273A
    _ZN27sqlusCPartRequestDescriptor11iDeallocateEv + 0x0006
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A987C65F1 _ZN18sqlusCPartSubAgent8iCleanUpEv + 0x03c1
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A987DAD4A _Z19sqlusSubAgentRouterP8sqeAgenti + 0x028e
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A973310E0 _Z20sqleSubRequestRouterP8sqeAgentPjS1_ +
    0x0324
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A973307B5 _Z21sqleProcessSubRequestP8sqeAgent + 0x005f
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A96941765 _ZN8sqeAgent6RunEDUEv + 0x04b7
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A96E4CE3D _ZN9sqzEDUObj9EDUDriverEv + 0x006d
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A96E4CDCD _Z10sqlzRunEDUPcj + 0x0009
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A96C32E06 sqloEDUEntry + 0x02ea
    
    (/view/db2_v95fp5_linuxamd64_s091123/vbs/INST/lib/libdb2e.so.1)
    0x0000002A95673919 address: 0x0000002A95673919 ; dladdress:
    0x0000002A9566D000 ; offset in lib: 0x0000000000006919 ;
                    (/lib64/tls/libpthread.so.0)
    0x0000002A9C497573 __clone + 0x0043
                    (/lib64/tls/libc.so.6)
    </StackTrace>
    
    If striptblanks or striptnulls option is used in the load
    command, then there may not be memory validation failure error
    entries in db2diag.log, but it will still show the db2lpart EDU
    crashing, and the stack trace may look like
    
    <StackTrace>
    -------Frame------ ------Function + Offset------
    0x090000000EB1FE10
    iPartitionData__18sqlusCPartSubAgentFP16sqluIMediaListIOT1 +
    0x3E4
    0x090000000E8BFD28 iRun__18sqlusCPartSubAgentFv + 0x96C
    0x090000000D7A8558 sqlusSubAgentRouter__FP8sqeAgenti + 0x8CC
    0x090000000D79C478 sqleSubRequestRouter__FP8sqeAgentPUiT2 +
    0x1008
    0x090000000D79AE58 sqleProcessSubRequest__FP8sqeAgent + 0x124
    0x090000000EA46D04 RunEDU__8sqeAgentFv + 0x300
    0x090000000DF79FCC EDUDriver__9sqzEDUObjFv + 0x78
    0x090000000DD14ED0 sqlzRunEDU__FPcUi + 0xC
    0x090000000DD14F18 sqloEDUEntry + 0x4
    </StackTrace>
    

Local fix

  • To correct usage of the db2 load option METHOD L (beginloc
    endloc), the offset of endloc must be greater or equal to
    beginloc.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * ALL                                                          *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * INSTANCE CRASH IN DPF ENVIRONMENT IF THERE IS A WRONG OFFSET *
    * INPUT TO METHOD L WHILE DOING A DB2 LOAD WITH ASC SOURCE     *
    * FILE.                                                        *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * Upgrade to v9.7 FP5                                          *
    *                                                              *
    * OR                                                           *
    *                                                              *
    * Accept below workaround:                                     *
    * To correct usage of the db2 load option METHOD L (beginloc   *
    *                                                              *
    * endloc), the offset of endloc must be greater or equal to    *
    *                                                              *
    * beginloc.                                                    *
    ****************************************************************
    

Problem conclusion

  • This APAR will be fixed in v9.7 FP5
    

Temporary fix

Comments

APAR Information

  • APAR number

    IC75339

  • Reported component name

    DB2 FOR LUW

  • Reported component ID

    DB2FORLUW

  • Reported release

    970

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2011-03-28

  • Closed date

    2011-12-07

  • Last modified date

    2012-01-03

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

    IC73633

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

Fix information

  • Fixed component name

    DB2 FOR LUW

  • Fixed component ID

    DB2FORLUW

Applicable component levels

  • R950 PSN

       UP

  • R970 PSN

       UP



Document information

More support for: DB2 for Linux, UNIX and Windows

Software version: 9.7

Reference #: IC75339

Modified date: 03 January 2012