Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Determine where my C program core dump on solaris

Reply
Thread Tools

Determine where my C program core dump on solaris

 
 
wong_powah@yahoo.ca
Guest
Posts: n/a
 
      08-31-2006
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;
}

 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      08-31-2006
http://www.velocityreviews.com/forums/(E-Mail 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?

--
Ian Collins.
 
Reply With Quote
 
 
 
 
wong_powah@yahoo.ca
Guest
Posts: n/a
 
      08-31-2006
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:
> (E-Mail 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?
>
> --
> Ian Collins.


 
Reply With Quote
 
jmcgill
Guest
Posts: n/a
 
      08-31-2006
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>
 
Reply With Quote
 
jmcgill
Guest
Posts: n/a
 
      08-31-2006
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.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      08-31-2006
(E-Mail Removed) wrote:

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

> Ian Collins wrote:
>
>>(E-Mail 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.

--
Ian Collins.
 
Reply With Quote
 
jmcgill
Guest
Posts: n/a
 
      08-31-2006
(E-Mail Removed) 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.
 
Reply With Quote
 
goose
Guest
Posts: n/a
 
      08-31-2006
(E-Mail Removed) 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
 
Reply With Quote
 
goose
Guest
Posts: n/a
 
      08-31-2006
(E-Mail Removed) 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
 
Reply With Quote
 
goose
Guest
Posts: n/a
 
      08-31-2006
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Dump complete java VM state as core dump (not via OS) possible? halfdog Java 12 02-21-2013 06:14 AM
Python 2.5 Core Dump on Solaris 8 Melissa Evans Python 5 11-16-2006 01:50 PM
Core Solo & Core Duo are not Core microarchitecture; 65nm Pentium M chips bigal Hardware 0 03-22-2006 11:24 AM
Cisco AP1200 core dump B Thompson Cisco 7 11-26-2005 03:59 AM
Read Core Dump file ns Cisco 8 05-26-2005 03:07 AM



Advertisments