Determine where my C program core dump on solaris

[wong_powah]

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;
}

 

[Ian Collins]

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?

 

[wong_powah]

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.

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?

 

[jmcgill]

goose wrote:

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]

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.

 

[Ian Collins]

(e-mail address removed) 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.

 

[jmcgill]

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.

 

[goose]

(e-mail address removed) wrote:

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>

 

[goose]

Ian Collins wrote:

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

 

[goose]

goose wrote:




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.

 

[Igmar Palsenberg]

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