Debugging techniques and core dumps (was Re: ebay - cardamatic)

[Tom Jennings]

On Mon, 14 Feb 2005, Eric Smith wrote:

> When I get a core dump, if it's not immediately obvious what was
> wrong, I load it into the debugger (gdb) to investigate it.  For
> gdb, the core dump filename is an optional command line parameter
> after the executable file.

Oh! gdb dumps! I was thinking more about line printer hex (octal)
dumps. Manual stack traces and all that sort of rot. I knew people
who could do that. And go through FORTRAN 4 code from the front
panel! That's outa my league!

You're right though, M$ people are S.O.L. Have to add a program to
get your system logs in ASCII!

> When I worked at Telebit on the Netblazer multiprotocol dialup
> router (the world's first dial-on-demand IP router),

Great things those Trailblazers were! six THOUSAND! bits/sec to
French Antilles or somesuch place. It was amazing.(*)

> customers were the best debugging capability we had.  In addition
> to being able to use them in the debugger for postmortem analysis,
> one of our most talented engineers, Bill, wrote a tool to "reanimate"
> a Netblazer core dump.  This worked because the Netblazer ran on
> a 386, and we had 386 and 486 BSDI Unix systems for development.
> Bill's tool took the core dump file, loaded it into the memory of
> a Unix process, patched some of the I/O routines, and let you
> execute it.  This was handy because we'd built a lot of special
> debug facilities into the Netblazer code, accessible through its
> CLI.

That's what you get when you hire Real Programmers :-)


(*) A quote, attribution long forgotten:

"America is the place where, you can buy a year's supply of
aspirin for one dollar, then use it up in two weeks."

Stuck with 56K, today, we whine.