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`strle n+0x18(10c76, ffbffbc4, ffbff441, 7b, 0, 0)
libc.so.1`print f+0xd8(10c70, ff2e87dc, ff2e87fa, ff2e8368, ff2e4280, 4)
__1cNcoredump_f unc6F_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]

wo********@yaho o.ca 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`strle n+0x18(10c76, ffbffbc4, ffbff441, 7b, 0, 0)
libc.so.1`print f+0xd8(10c70, ff2e87dc, ff2e87fa, ff2e8368, ff2e4280, 4)
__1cNcoredump_f unc6F_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.

[goose]

wo********@yaho o.ca 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`strle n+0x18(10c76, ffbffbc4, ffbff441, 7b, 0, 0)
libc.so.1`print f+0xd8(10c70, ff2e87dc, ff2e87fa, ff2e8368, ff2e4280, 4)
__1cNcoredump_f unc6F_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

[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.

Ian Collins wrote:

wo********@yaho o.ca 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`strle n+0x18(10c76, ffbffbc4, ffbff441, 7b, 0, 0)
libc.so.1`print f+0xd8(10c70, ff2e87dc, ff2e87fa, ff2e8368, ff2e4280, 4)
__1cNcoredump_f unc6F_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.

[jmcgill]

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]

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.

[goose]

wo********@yaho o.ca 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

[Ian Collins]

wo********@yaho o.ca wrote:

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

Ian Collins wrote:

>>wo********@ya hoo.ca 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_fun c function of a test program caused the

core dump?

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

libc.so.1`st rlen+0x18(10c76 , ffbffbc4, ffbff441, 7b, 0, 0)
libc.so.1`pr intf+0xd8(10c70 , ff2e87dc, ff2e87fa, ff2e8368, ff2e4280, 4)
__1cNcoredum p_func6F_i_+0x2 0(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.

[jmcgill]

wo********@yaho o.ca wrote:

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

man truss

Followup-to: comp.unix.solar is

Please don't top-post there either.

[goose]

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