Hai all, core dump issue... - HP UX

This is a discussion on Hai all, core dump issue... - HP UX ; Hi all, The below is the full backtrace of a core dump i am debugging through gdb. Can any one tell me what is the error with it. I could find out the following: (gdb) backtrace full #0 0xc027aee8 in ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Hai all, core dump issue...

  1. Hai all, core dump issue...

    Hi all,

    The below is the full backtrace of a core dump i am debugging through
    gdb. Can any one tell me what is the error with it. I could find out
    the following:

    (gdb) backtrace full
    #0 0xc027aee8 in kill () from /usr/lib/libc.2
    No symbol table info available.
    #1 0xc01d8908 in _raise (sig=6) at
    .../../../../../core/libs/libc/shared_pa2_32/../core/gen/raise.c:19
    No locals.
    #2 0xc024143c in _abort_C () at
    .../../../../../core/libs/libc/shared_pa2_32/../core/gen/abort_C.c:101
    act = {__handler = {__sa_sigaction = 0, __sa_handler = 0},
    sa_mask = {sigset = {0, 0, 0, 0, 0, 0, 0,
    0}}, sa_flags = 0}
    set = {sigset = {32, 0, 0, 0, 0, 0, 0, 0}}
    __saved_state = 1209905216
    #3 0xc02414cc in abort () from /usr/lib/libc.2
    No symbol table info available.
    #4 0x2d2c4 in $000003F6 () at
    /sablime/builds/odw8/src/odw8_00.08/ore/exe/oreloader/sighand.cpp:211
    No locals.
    #5
    No symbol table info available.
    #6 0xc01c0578 in real_malloc (arena_id=0, nbytes=136)
    at
    .../../../../../core/libs/libc/shared_pa2_32/../core/gen/malloc.c:2676
    freeblock = (struct nodetype *) 0xc01c0653
    s = 3223062099
    new_base = 1075506852
    prev_curbrk = 2
    allocptr = (unsigned long *) 0x20202020
    tempblk = (unsigned long *) 0x4000cbe0
    ---Type to continue, or q to quit---
    i = 2062999800
    index = 16
    hblk = (struct holdheadtype *) 0x4000cc18
    set = {sigset = {640942072, 0, 2139054052, 124, 2063881216,
    2063832980, 1, 3223062099}}
    oset = {sigset = {3223062099, 0, 1074580908, 1077018692,
    1073940266, 2062999800, 0, 1073793624}}
    #7 0xc01bd3cc in _malloc (nbytes=136)
    at
    .../../../../../core/libs/libc/shared_pa2_32/../core/gen/malloc.c:1777
    arena_id = 2062999800
    i = 4
    ptr = (signed char *) 0x4000cac8 ""
    #8 0xc01c714c in malloc (size=136) at
    .../../../../../core/libs/libc/shared_pa2_32/../core/gen/malloc.c:4930
    ptr = (signed char *) 0x40320048 "@@MCFLAG"
    #9 0xc2919f68 in cdc_malloc (size=136)
    at
    /sablime/builds/odw8/src/odw8_00.01/ore/legacy/udk/cdclibs/util/cdcu.c:1248
    func = "cdc_malloc"
    ptr = (signed char *) 0x40320038 "pkey"
    #10 0xc291df18 in lcdc_db_copy_sqlvar (src_sqlda=0x4030a860)
    at
    /sablime/builds/odw8/src/odw8_00.06/ore/legacy/udk/cdclibs/util/dbd/inf/cdc_db_desc.ec:381
    func = "lcdc_db_copy_sqlvar"
    dest_sqlvar = (struct sqlvar_struct *) 0x0
    tmp_dest_sqlvar = (struct sqlvar_struct *) 0x0
    current_col = (struct sqlvar_struct *) 0x4030a7d0
    i = 5


  2. Re: Hai all, core dump issue...

    "Naveen" writes:

    > The below is the full backtrace of a core dump i am debugging through
    > gdb. Can any one tell me what is the error with it. I could find out
    > the following:


    Any crash in malloc() internals (which is what's happening in your
    case) is a result of heap corruption (with 99.99% probablility).

    Heap corruption usually results from free()ing un-allocated memory,
    free()ing something twice, writing beyond the end (or before start)
    of allocated storage.

    Unfortunately, these bugs are often hard to find, because the root
    cause is usually far removed from where the crash happens.

    Fortunately, there exist many malloc debuggers (google is your
    friend) to help you, as well as specialized tools, such as Purify
    and Insure++.

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  3. Re: Hai all, core dump issue...

    > Any crash in malloc() internals (which is what's happening in your
    > case) is a result of heap corruption (with 99.99% probablility).
    >
    > Heap corruption usually results from free()ing un-allocated memory,
    > free()ing something twice, writing beyond the end (or before start)
    > of allocated storage.
    >
    > Unfortunately, these bugs are often hard to find, because the root
    > cause is usually far removed from where the crash happens.
    >
    > Fortunately, there exist many malloc debuggers (google is your
    > friend) to help you, as well as specialized tools, such as Purify
    > and Insure++.


    On HP-UX there is a heap-checking facility built into the free WDB
    debugger. Look for "info corruption" in the documentation at
    www.hp.com/go/wdb. You can also download the latest version from
    there. The current WDB 5.5 version will stop the debugger at athe
    exact memcpy/memset/strcpy call that is about to write off the end and
    corrupt a heap block.


    - Carl Burch

    HP WDB Team


  4. Re: Hai all, core dump issue...

    thank you all for the replies... I will try WDB and get back to it.

    On Oct 5, 10:31 pm, "Carl Burch" wrote:
    > > Any crash in malloc() internals (which is what's happening in your
    > > case) is a result of heap corruption (with 99.99% probablility).

    >
    > > Heap corruption usually results from free()ing un-allocated memory,
    > > free()ing something twice, writing beyond the end (or before start)
    > > of allocated storage.

    >
    > > Unfortunately, these bugs are often hard to find, because the root
    > > cause is usually far removed from where the crash happens.

    >
    > > Fortunately, there exist many malloc debuggers (google is your
    > > friend) to help you, as well as specialized tools, such as Purify
    > > and Insure++. On HP-UX there is a heap-checking facility built into the free WDB

    > debugger. Look for "info corruption" in the documentation atwww.hp.com/go/wdb. You can also download the latest version from
    > there. The current WDB 5.5 version will stop the debugger at athe
    > exact memcpy/memset/strcpy call that is about to write off the end and
    > corrupt a heap block.
    >
    > - Carl Burch
    >
    > HP WDB Team



+ Reply to Thread