Determine where my C program core dump on solaris

Discussion in 'C Programming' started by wong_powah@yahoo.ca, Aug 31, 2006.

  1. Guest

    I want to find out where (which line) my C program core dump.
    How to do that?
    Is there a web site describing the procedure?

    One approach is to use stack trace of the mdb debugger, but I does not
    understand its output completely.

    e.g. How to interpret the stack trace to find out which line inside the
    coredump_func function of a test program caused the

    core dump?

    $ CC -g coredump_fn.c
    $ a.out
    hello
    Segmentation Fault (core dumped)
    $ mdb core
    Loading modules: [ libc.so.1 ld.so.1 ]
    > ::stack

    libc.so.1`strlen+0x18(10c76, ffbffbc4, ffbff441, 7b, 0, 0)
    libc.so.1`printf+0xd8(10c70, ff2e87dc, ff2e87fa, ff2e8368, ff2e4280, 4)
    __1cNcoredump_func6F_i_+0x20(6, ff2e87dc, ff2e87fa, ff2e8368, ff2e4280,
    6)
    main+0x20(1, ffbffcbc, ffbffcc4, 20c00, ff3301c0, ff330200)
    _start+0xb8(0, 0, 0, 0, 0, 0)
    >



    /* coredump_fn.c : C test program for core dump generation */

    #include <stdio.h>

    int coredump_func() {
    char *ptr = 0;
    ptr = (char *) 123;
    printf("ptr %s\n", ptr);
    return 0;
    }

    int main(int argc, char *argv[])
    {
    int i = 0;
    double x;

    printf("hello\n");
    coredump_func();
    x = 1.0 / i;
    printf("x %f\n", x);

    return 0;
    }
     
    , Aug 31, 2006
    #1
    1. Advertising

  2. Ian Collins Guest

    wrote:
    > I want to find out where (which line) my C program core dump.
    > How to do that?
    > Is there a web site describing the procedure?
    >
    > One approach is to use stack trace of the mdb debugger, but I does not
    > understand its output completely.
    >
    > e.g. How to interpret the stack trace to find out which line inside the
    > coredump_func function of a test program caused the
    >
    > core dump?
    >
    > $ CC -g coredump_fn.c
    > $ a.out
    > hello
    > Segmentation Fault (core dumped)
    > $ mdb core
    > Loading modules: [ libc.so.1 ld.so.1 ]
    >
    >> ::stack

    >
    > libc.so.1`strlen+0x18(10c76, ffbffbc4, ffbff441, 7b, 0, 0)
    > libc.so.1`printf+0xd8(10c70, ff2e87dc, ff2e87fa, ff2e8368, ff2e4280, 4)
    > __1cNcoredump_func6F_i_+0x20(6, ff2e87dc, ff2e87fa, ff2e8368, ff2e4280,
    > 6)
    > main+0x20(1, ffbffcbc, ffbffcc4, 20c00, ff3301c0, ff330200)
    > _start+0xb8(0, 0, 0, 0, 0, 0)
    >

    OT here, but isn't it obvious that you are passing crap to printf which
    causes strlen to barf?

    --
    Ian Collins.
     
    Ian Collins, Aug 31, 2006
    #2
    1. Advertising

  3. Guest

    My goal is to find a general method to determine where a (long) C
    program core dump.
    Therefore I intentionally create a very short test program which will
    core dump, then evaluate how good is the general method.
    Here I try "mdb core" as the general method, which may or may not be
    the best method.

    Ian Collins wrote:
    > wrote:
    > > I want to find out where (which line) my C program core dump.
    > > How to do that?
    > > Is there a web site describing the procedure?
    > >
    > > One approach is to use stack trace of the mdb debugger, but I does not
    > > understand its output completely.
    > >
    > > e.g. How to interpret the stack trace to find out which line inside the
    > > coredump_func function of a test program caused the
    > >
    > > core dump?
    > >
    > > $ CC -g coredump_fn.c
    > > $ a.out
    > > hello
    > > Segmentation Fault (core dumped)
    > > $ mdb core
    > > Loading modules: [ libc.so.1 ld.so.1 ]
    > >
    > >> ::stack

    > >
    > > libc.so.1`strlen+0x18(10c76, ffbffbc4, ffbff441, 7b, 0, 0)
    > > libc.so.1`printf+0xd8(10c70, ff2e87dc, ff2e87fa, ff2e8368, ff2e4280, 4)
    > > __1cNcoredump_func6F_i_+0x20(6, ff2e87dc, ff2e87fa, ff2e8368, ff2e4280,
    > > 6)
    > > main+0x20(1, ffbffcbc, ffbffcc4, 20c00, ff3301c0, ff330200)
    > > _start+0xb8(0, 0, 0, 0, 0, 0)
    > >

    > OT here, but isn't it obvious that you are passing crap to printf which
    > causes strlen to barf?
    >
    > --
    > Ian Collins.
     
    , Aug 31, 2006
    #3
  4. jmcgill Guest

    goose wrote:

    <ot>
    > I would guess that the stack trace above is
    > simply means main calls printf which calls strlen.


    I gathered that the OP knows this quite well, and had contrived the
    example to illustrate his question, which is about analyzing core dumps
    using a particular debugger.

    I tend to use truss or strace to find out where such things are failing,
    because it's a lot easier to do that than to mess with the debugger.

    </ot>
     
    jmcgill, Aug 31, 2006
    #4
  5. jmcgill Guest

    Ian Collins wrote:

    > OT here, but isn't it obvious that you are passing crap to printf which
    > causes strlen to barf?



    The OP cooked up the example in order to make it obvious. He's not
    asking why the program crashes, he's asking how to analyze that kind of
    crash in the debugger.
     
    jmcgill, Aug 31, 2006
    #5
  6. Ian Collins Guest

    wrote:

    Please don't top post, see <http://www.caliburn.nl/topposting.html>.

    > Ian Collins wrote:
    >
    >> wrote:
    >>
    >>>I want to find out where (which line) my C program core dump.
    >>>How to do that?
    >>>Is there a web site describing the procedure?
    >>>
    >>>One approach is to use stack trace of the mdb debugger, but I does not
    >>>understand its output completely.
    >>>
    >>>e.g. How to interpret the stack trace to find out which line inside the
    >>>coredump_func function of a test program caused the
    >>>
    >>>core dump?
    >>>
    >>>$ CC -g coredump_fn.c
    >>>$ a.out
    >>>hello
    >>>Segmentation Fault (core dumped)
    >>>$ mdb core
    >>>Loading modules: [ libc.so.1 ld.so.1 ]
    >>>
    >>>
    >>>>::stack
    >>>
    >>>libc.so.1`strlen+0x18(10c76, ffbffbc4, ffbff441, 7b, 0, 0)
    >>>libc.so.1`printf+0xd8(10c70, ff2e87dc, ff2e87fa, ff2e8368, ff2e4280, 4)
    >>>__1cNcoredump_func6F_i_+0x20(6, ff2e87dc, ff2e87fa, ff2e8368, ff2e4280,
    >>>6)
    >>>main+0x20(1, ffbffcbc, ffbffcc4, 20c00, ff3301c0, ff330200)
    >>>_start+0xb8(0, 0, 0, 0, 0, 0)
    >>>

    >>
    >>OT here, but isn't it obvious that you are passing crap to printf which
    >>causes strlen to barf?
    >>

    > My goal is to find a general method to determine where a (long) C
    > program core dump.
    > Therefore I intentionally create a very short test program which will
    > core dump, then evaluate how good is the general method.
    > Here I try "mdb core" as the general method, which may or may not be
    > the best method.
    >

    What ever you do will be system and tool specific.

    Pick a tool, understand its output and maybe write an script of program
    to parse the output if you wish to simplify it.

    --
    Ian Collins.
     
    Ian Collins, Aug 31, 2006
    #6
  7. jmcgill Guest

    wrote:
    > My goal is to find a general method to determine where a (long) C
    > program core dump.


    man truss

    Followup-to: comp.unix.solaris

    Please don't top-post there either.
     
    jmcgill, Aug 31, 2006
    #7
  8. goose Guest

    wrote:

    <snipped>

    > e.g. How to interpret the stack trace to find out which line inside the
    > coredump_func function of a test program caused the
    >
    > core dump?
    >
    > $ CC -g coredump_fn.c
    > $ a.out
    > hello
    > Segmentation Fault (core dumped)
    > $ mdb core
    > Loading modules: [ libc.so.1 ld.so.1 ]
    >
    >> ::stack

    >
    > libc.so.1`strlen+0x18(10c76, ffbffbc4, ffbff441, 7b, 0, 0)
    > libc.so.1`printf+0xd8(10c70, ff2e87dc, ff2e87fa, ff2e8368, ff2e4280, 4)
    > __1cNcoredump_func6F_i_+0x20(6, ff2e87dc, ff2e87fa, ff2e8368, ff2e4280,
    > 6)
    > main+0x20(1, ffbffcbc, ffbffcc4, 20c00, ff3301c0, ff330200)
    > _start+0xb8(0, 0, 0, 0, 0, 0)
    >


    <ot>
    I would guess that the stack trace above is
    simply means main calls printf which calls strlen.

    So, in main(), look for a printf call which uses
    a %s format specifier. The string for that %s is
    missing, munged, or simply NULL.

    </ot>

    You'll get more reliable information if you post
    to a group where this is on-topic.

    <snipped>

    --
    Have I offended you? Send flames to root@localhost
    real email: lelanthran at gmail dot com
    website : www.lelanthran.com
     
    goose, Aug 31, 2006
    #8
  9. goose Guest

    wrote:
    <fixed top-posting>
    > Ian Collins wrote:
    >

    <snipped>
    >>OT here, but isn't it obvious that you are passing crap to printf which
    >>causes strlen to barf?
    >>


    a) As Ian Collins pointed out, this is off-topic.
    b) Don't top-post.


    --
    Have I offended you? Send flames to root@localhost
    real email: lelanthran at gmail dot com
    website : www.lelanthran.com
     
    goose, Aug 31, 2006
    #9
  10. goose Guest

    jmcgill wrote:
    > goose wrote:
    >
    > <ot>
    >
    >>I would guess that the stack trace above is
    >>simply means main calls printf which calls strlen.

    >
    >
    > I gathered that the OP knows this quite well, and had contrived the
    > example to illustrate his question, which is about analyzing core dumps
    > using a particular debugger.
    >


    And I very tersely(sp?) showed him how to do this
    without even looking at the source. I explained what
    the (now snipped) stack trace *means*. That is what
    was requested, AIUI?

    > I tend to use truss or strace to find out where such things are failing,
    > because it's a lot easier to do that than to mess with the debugger.
    >


    Oh, I don't know about that; on the rare occassion that
    my program crashes, I simply look at the stack trace
    left behind in the core file (gdb loads corefiles). I've
    not yet *really* needed to step through a debugger,
    although I have used them in the embedded space.

    > </ot>



    --
    Have I offended you? Send flames to root@localhost
    real email: lelanthran at gmail dot com
    website : www.lelanthran.com
     
    goose, Aug 31, 2006
    #10
  11. wrote:
    > I want to find out where (which line) my C program core dump.
    > How to do that?
    > Is there a web site describing the procedure?


    [igmar@ouzo ~]$ ./xxx
    hello
    Segmentation fault (core dumped)

    [igmar@ouzo ~]$ gdb ./xxx core.11726
    <snip license info>
    Core was generated by `./xxx'.
    Program terminated with signal 11, Segmentation fault.
    Reading symbols from /lib/tls/libc.so.6...done.
    Loaded symbols for /lib/tls/libc.so.6
    Reading symbols from /lib/ld-linux.so.2...done.
    Loaded symbols for /lib/ld-linux.so.2
    #0 0x41bec2bb in strlen () from /lib/tls/libc.so.6
    (gdb) bt
    #0 0x41bec2bb in strlen () from /lib/tls/libc.so.6
    #1 0x41bc0225 in vfprintf () from /lib/tls/libc.so.6
    #2 0x41bc55e0 in printf () from /lib/tls/libc.so.6
    #3 0x08048364 in coredump_func () at xxx.c:8
    #4 0x080483a6 in main (argc=1, argv=0xbf951034) at xxx.c:18

    The above could be automated.




    Igmar
     
    Igmar Palsenberg, Sep 1, 2006
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike
    Replies:
    0
    Views:
    731
  2. BlueDoze
    Replies:
    2
    Views:
    1,192
    Gordon Beaton
    May 4, 2004
  3. Amit
    Replies:
    0
    Views:
    1,017
  4. halfdog
    Replies:
    12
    Views:
    12,551
  5. Melissa Evans

    Python 2.5 Core Dump on Solaris 8

    Melissa Evans, Nov 10, 2006, in forum: Python
    Replies:
    5
    Views:
    592
    =?ISO-8859-1?Q?Michael_Str=F6der?=
    Nov 16, 2006
Loading...

Share This Page