From: Christoph Egger <Christoph_Egger@t-online.de>
  To  : GGI-Mailing-Liste <ggi-develop@eskimo.com>
  Date: Tue, 13 Jul 1999 07:02:22 +0200 (MEST)

Re: hacking methods to find out bugs

On Mon, 12 Jul 1999, Peter Amstutz wrote:

> 
> On Mon, 12 Jul 1999, Christoph Egger wrote:
> 
> > On Mon, 12 Jul 1999, Jon M. Taylor wrote:
> > 
> > > On Mon, 12 Jul 1999, Christoph Egger wrote:
> > > 
> > > > 
> > > > Hi all!
> > > > 
> > > > I have tried to debug my lib with ddd again. Now I found some bugs, but
> > > > not all.
> > > > 
> > > > 
> > > > program exited with SIGSEGV at 0x400e807
> > > > 
> > > > 
> > > > How can I find out with this ddd error, what is buggy? I have no
> > > > experience about memory dumbing... Can anyone help me?
> > > 
> > > 	What is usually do with a bugs like this is to fall back to using
> > > printf() (or the equivalent) to zero in on the line which is causing the
> > > segfault.  Crude but often quite effective debugging technique.  Once you 
> > > have found the line which is causing the segfault, most of the time the 
> > > problem will jump out at you.
> > 
> > Can you give an example?
> 
> This is a pretty basic debugging skill, but in a nutshell:
> 
> somefunction(...) {
> 	/* some possibly buggy code */
> 	printf("Checkpoint #1\n");
> 	/* more possibly buggy code */
> 	printf("Checkpoint #2\n");
> 	/* even more possibly buggy code */	
> 	printf("Checkpoint #3\n");
> }
> 
> Then look for the last "Checkpoint" statement that was printed out before
> things blew up.  That will give you an idea of where the code failed.  
> For example, if it prints out "Checkpoint #1" and "Checkpoint #2" but NOT
> "Checkpoint #3" then clearly the failure happened somewhere in the "even
> more possibly buggy code" block.
> 
> Of course you can print anything, recently I was doing some debugging like
> this using the names of several japanese and european cities, intermixed
> with four-letter words (a rather naughty race condition that may still be
> lurking in there, unfortunatly, hence the foul language :)
> 

Ah - OK. But I think, with printf's I can't detect all bugs. Example:

        light1 = fix_light_create(itofix(+700), itofix(0), itofix(100));
        SetLightambient(80);
        fix_light_setcolor(light1, 255,255,255);
        fix_light_setrange(light1, itofix(6000));
        fix_light_setbrightness(light1, 128);

light1 is a unsigned long variable. The printf's says, that the variable
has the expected value: 1. The debugger ddd instead says, that the
variable has a very big value ( 20th digit's ), which changes every
time...

Could that be a stack corruption?

Cheers,

Christoph Egger
E-Mail: Christoph_Egger@t-online.de