dumping core in calloc - Unix

This is a discussion on dumping core in calloc - Unix ; Hi I am debugging multithreaded/netowrk prog code, It dumps core hostname% gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/ specs gcc version 2.95.3 20010315 (release) icprg04% uname -a SunOS 5.10 Generic_118822-30 sun4u sparc SUNW,Sun-Fire-280R ====cut paste from dbx session this is ***dbx ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: dumping core in calloc

  1. dumping core in calloc

    Hi

    I am debugging multithreaded/netowrk prog code, It dumps core

    hostname% gcc -v
    Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/
    specs
    gcc version 2.95.3 20010315 (release)

    icprg04% uname -a
    SunOS 5.10 Generic_118822-30 sun4u sparc SUNW,Sun-Fire-280R

    ====cut paste from dbx session this is ***dbx ./binary-name ./core ***
    ====
    (dbx) thread t@65
    Current function is get_remote_thick_profile
    392 if (((*list) = (char *) calloc (1, sizeof (char))) ==
    (char *)NULL)
    t@65 (l@65) stopped in realfree at 0xff0d4834
    0xff0d4834: realfree+0x00ec: st %l0, [%i0 + %o1]
    (dbx) where
    current thread: t@65
    [1] realfree(0xf0628, 0x400, 0x93b28, 0x494e3240, 0x0, 0xf0a38), at
    0xff0d4834
    [2] cleanfree(0x0, 0x10, 0x93278, 0xff139980, 0xff168284,
    0xff16fad4), at 0xff0d505c
    [3] _malloc_unlocked(0x8, 0x18, 0xec398, 0xec3a0, 0xffffffff,
    0xfefa1000), at 0xff0d41b4
    [4] malloc(0x1, 0x1, 0x94224, 0xff16fa90, 0xff168284, 0xff1709b0),
    at 0xff0d40a4
    [5] calloc(0x1, 0x1, 0x1, 0xff139980, 0xfefa1000, 0x1000), at
    0xff0c0e68
    Other Function call

    Interestingly Calloc is called as below ! and it is crashing.;
    392 if (((*list) = (char *) calloc (1, sizeof (char))) ==
    (char *)NULL)


    What i guess is...

    1. Definetly this calloc is not source of bug, but there MAY be memory
    corruption elsewhere.
    2. Is this Bug ? ideally calloc should not crash like this way. and
    debugger should give me the source of real-error


    --Raxit

  2. Re: dumping core in calloc

    Sheth Raxit writes:

    >1. Definetly this calloc is not source of bug, but there MAY be memory
    >corruption elsewhere.


    There *IS* memory corruption somewhere.

    >2. Is this Bug ? ideally calloc should not crash like this way. and
    >debugger should give me the source of real-error


    If you corrupt memory, anything can happen...

    On Solairs (which is what you seem to be running) there are various
    different debugging memory allocators, depending on your OS revisions.

    There's watchmalloc (which uses hardware watchpoints) and there's
    libumem (which does the same sort of bookkeeping as the kernel)

    Both detect different forms of corruption at different times.
    Libumem also has the ability to help with leak detection.

    If you are really running Solaris 8 (the gcc version seems to indicate
    this) then libumem is not available, I think.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  3. Re: dumping core in calloc

    On Dec 4, 7:17 pm, Casper H.S. Dik wrote:
    > Sheth Raxit writes:
    > >1. Definetly this calloc is not source of bug, but there MAY be memory
    > >corruption elsewhere.

    >
    > There *IS* memory corruption somewhere.

    agree
    >
    > >2. Is this Bug ? ideally calloc should not crash like this way. and
    > >debugger should give me the source of real-error

    >
    > If you corrupt memory, anything can happen...

    wow !
    >
    > On Solairs (which is what you seem to be running) there are various

    running Sun OS 5.10 as uname -a output above.
    > different debugging memory allocators, depending on your OS revisions.
    >
    > There's watchmalloc (which uses hardware watchpoints) and there's
    > libumem (which does the same sort of bookkeeping as the kernel)
    >

    having dbx installed but still find very differnt from gdb.! the
    process is doing continuous process and very much unfamiliur with mdb.

    > Both detect different forms of corruption at different times.
    > Libumem also has the ability to help with leak detection.

    nothing easy like valgrind. < I am not running any kernel level
    software and valgrind on linux is very simple and easy.>
    >
    > If you are really running Solaris 8 (the gcc version seems to indicate

    no
    > this) then libumem is not available, I think.


    >
    > Casper
    > --

    Raxit

  4. Re: dumping core in calloc

    Sheth Raxit writes:

    >> There's watchmalloc (which uses hardware watchpoints) and there's
    >> libumem (which does the same sort of bookkeeping as the kernel)
    >>

    >having dbx installed but still find very differnt from gdb.! the
    >process is doing continuous process and very much unfamiliur with mdb.


    If you run with libumem (man umem_debug; run the application with:

    env UMEM_DEBUG=default LD_PRELOAD=libumem.so.1 prog [arg ...]

    then when the application cores, run with mdb:

    mdb core

    and run the appropriate umem commands to look for corruption.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

+ Reply to Thread