Very Computer

Our users frequently get core dumps from our huge application, and in order to
facilite our debugging they often feel the need to email us these 650Mb core
files, or more likely they just set "limit core 0" and forget about it.  All
we really need is the backtrace from the core file, but many of them don't
have dbx, and even the ones that do can't be bothered to start up dbx then
type "where".  So we end up with a lot of complaints about core dumps, but no
help in narrowing down where and why these are happening.

We are thinking about shipping gdb with our product in order to help the ones
who don't have dbx.  But first I thought I'd have a poke around to see if
there is an easy way to *just* get the backtrace from a core file without all
the overhead of a huge de*.  Is there a program that would do that for
me?  This is Irix 6.2 on various SGI platforms.  Alternatively, is there a
signal handler I could add to the program that would print out a stack trace
before dying *without* dumping core?

--
Paul Tomblin, Current Product Engineering team leader.
I don't speak for Kodak, they don't speak for me.

"You are in a twisty maze of Motif Widget resources, all inconsistent."

--
Justin Banks
Silicon Graphics Cray Research
Eagan, Minnesota

Expires: 05 Jul 1997 05:45:03 -0000

comp.unix.programmer FAQ: <URL: http://www.veryComputer.com/;

6.5 How can I generate a stack dump from within a running program?

With the information in that reference, you should be able to reduce your
users' ability to produce core files by a couple of orders of magnitude.

Quote:>Our users frequently get core dumps from our huge application, and in order to
>facilite our debugging they often feel the need to email us these 650Mb core
>files, or more likely they just set "limit core 0" and forget about it.  All
>we really need is the backtrace from the core file, but many of them don't
>have dbx, and even the ones that do can't be bothered to start up dbx then
>type "where".  So we end up with a lot of complaints about core dumps, but no
>help in narrowing down where and why these are happening.

>We are thinking about shipping gdb with our product in order to help the ones
>who don't have dbx.  But first I thought I'd have a poke around to see if
>there is an easy way to *just* get the backtrace from a core file without all
>the overhead of a huge de*.  Is there a program that would do that for
>me?  This is Irix 6.2 on various SGI platforms.  Alternatively, is there a
>signal handler I could add to the program that would print out a stack trace
>before dying *without* dumping core?

If someone knows a better way I would be very eager to hear.

Quote:>comp.unix.programmer FAQ: <URL: http://www.erlenstar.demon.co.uk/unix/>

>6.5 How can I generate a stack dump from within a running program?

>With the information in that reference, you should be able to reduce your
>users' ability to produce core files by a couple of orders of magnitude.

Quote:>>have dbx, and even the ones that do can't be bothered to start up dbx then

Which is why I asked the question AFTER READING THE FAQ in the first place.

Thanks but no thanks.
--
Paul Tomblin, Current Product Engineering team leader.
I don't speak for Kodak, they don't speak for me.

"You are in a twisty maze of Motif Widget resources, all inconsistent."

--
Paul Tomblin, Current Product Engineering team leader.
I don't speak for Kodak, they don't speak for me.

"You are in a twisty maze of Motif Widget resources, all inconsistent."

I am sorry that my - fairly snide - response did not respond to every
word in your original posting. I NOW know that you have read the FAQ. In
your situation, I would be inclined to investigate the balance between
shipping gdb and a configuration decision as to which de* to use if
I had customers who had no de* and living with a much reduced
number of core files. (I infer from "Unix in a Nutshell" that sdb and
dbx should cover most ports.) Regardless, the FAQ's technique seems good
to me as it uses work from someone else in matching the real and
conceptual machines. You could always look at a stripped down gdb but
that is WORK and a support nightmare. MY experience of traceback reports
comes from VMS where they are a normal response to an illegal operation
and where I would have considered killing for a dump as useful as core!

Look on the MIT X11R6 distribution. In the utils subdirectory there used
to be a malloc debugging library. This included source for mips,ix86 and
sparc to parse the stack and generate a numeric backtrace. There was an
awk script to that took these addreses and run nm on the binary to produce
a verbose back stack trace...  It is also possible to obtain the symbol
names without using nm by reading the symbol table from the executable.
Depends how much trouble you want to go to... I did post an library
on alt.sources a little while back for a utility that part of what it
did was generate a stack back trace...

cheers

Rich

Alternatively, (and this is ugly), what about writing a small stack
traversal routine yourself? Look in frame.h.  Catch the offending
signal, and just walk the stack back, we do that here with a piece of
assembly code that returns an array of up to 25 stack frame
pointers. (We are working with HP-UX 10.20).

A shell script could be written around nm and a few other tools to
postprocess the stack trace and the core file, producing parameters
and at least some symbol names.  If you have decent run-time symbol
support from a library of some-sorts, you could likely get the symbols
at crash time.

--
Alan Hawrylyshen           | The opinions expressed above are my own.
Vancouver, BC, Canada      | ICBM :  N04910.466' W12304.347' WGS84