467,173 Members | 1,330 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,173 developers. It's quick & easy.

Determine where my C program core dump on solaris

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 '06 #1
  • viewed: 7045
Share:
10 Replies
wo********@yahoo.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`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 '06 #2
wo********@yahoo.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`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
Aug 31 '06 #3
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********@yahoo.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`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 '06 #4
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>
Aug 31 '06 #5
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.
Aug 31 '06 #6
wo********@yahoo.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
Aug 31 '06 #7
wo********@yahoo.ca wrote:

Please don't top post, see <http://www.caliburn.nl/topposting.html>.
Ian Collins wrote:
>>wo********@yahoo.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`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.
Aug 31 '06 #8
wo********@yahoo.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.solaris

Please don't top-post there either.
Aug 31 '06 #9
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
Aug 31 '06 #10
wo********@yahoo.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?
[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
Sep 1 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Dave Harrison | last post: by
2 posts views Thread by Johan den Boer | last post: by
1 post views Thread by Martin | last post: by
1 post views Thread by Martin | last post: by
21 posts views Thread by Joakim Hove | last post: by
5 posts views Thread by Melissa Evans | last post: by
1 post views Thread by gquiring@gmail.com | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.