From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Tue, 13 Jul 1999 01:30:10 +1000

Re: hacking methods to find out bugs

Christoph Egger writes:

>  On Mon, 12 Jul 1999, Andrew Apted wrote:
>  
>  > Or run in X and use gdb (hacking libgg so that it doesn't catch SIGSEGV
>  > and prevent a core dump).
>  
>  With "hacking a lib so that it doesn't catch SIGSEGV" you mean I should
>  fix the bug to find the bug?
 
Nah.  Normally on UNIX, a SIGSEGV signal will produce a core dump. 
The LibGG library (in the LibGII tarball) catches that signal (etc) so
that graphics can be restored sanely.  But this means no core dump.

Thus I tend to hack it (the file libgii/gg/cleanup.c) and comment out
the SIGSEGV part to get the core dumps.

>  What is a core dump?

Compared to adding printfs: heaven ;-).

It's just a big file (sometimes REALLY big), called "core", which is a
snapshot of the memory of the program when it did the illegal act.  

Then you run GDB on it (like this: "gdb mybuggyprog core"), and if you
compiled the program with debugging info ("-g" option), you can look at
the stack backtrace & the functions which were executing & all the
variables.

Now go and RTFMs ;-)

>  > "weird" bugs are _always_ the worst. Stack corruption is one that is
>  > very nasty -- I once debugged a stack corruption problem, detecting it
>  > by setting a local variable of some procedure (higher than the buggy
>  > one) to a known value and checking it at various places.
>  
>  hmm... and how are you fixed this stack corruption problem?

Took out #ifdefs from the structs ;-).

Cheers,
___________________________________________________
                                               \  /
  Andrew Apted   <ajapted@netspace.net.au>      \/