Re: stack trace generation

I wrote:
>In response to my Summary about using BFD for stack traces, I received a
>few interesting messages. One suggested the horrible-seeming but actually
>quite useful hack of forking a process that dumps core and then running a
>debugger like gdb or dbx on it. I think it's a neat idea, and so I coded
>it up: included below. Let me know if there's portability problems getting
>it to work on other UNIX platforms.


The code I included had 2 bugs kindly pointed out by Norman Ramsey.
1) should wait for the first child to finish dumping core before firing off
the debugger;
2) while(wait(NULL)>0) waits for all children, and could hang.


I've fixed this by putting the loop "while(wait(NULL) != pid) {}"
in two places, just after both /* Parent continues */ comments.


Also, I've found some more info on stack traces for SunOS and IBM AIX:
Here's the info from an old message in my news archives:


# Thanks to John at the Ohio Company, here's the info per the Sept '92
# issue of Dr. Dobb's titled "Crash Tracebacks in UNIX":
#
# ftp.mv.com /pub/ddj/1992.09/trace.arc
#
# You would also need to get the DOS program /pub/ddj/packages/arce.com
# to uncrunch the .arc file (type "arce trace" in DOS).
#
# The file DUNHAM.LS7 is the source for sparc.c.
# FRAMEDUMP and SYMBOLDUMP should be #defined to 1.
# trb_signalinit(argc,argv) seems to be the main entry point.
#
# By default, the stack trace goes to the file CRASH in the current
# directory. You can create a read-only file named CRASH to force
# it to go to stderr.


Any more suggestions about run-time libraries for stack traces welcome.


Regards,
David Spuler
--

Return to the comp.compilers page.
Search the comp.compilers archives again.