Xref: news2.mv.net comp.os.msdos.djgpp:7236
From: broeker AT I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN (Hans-Bernhard Broeker)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Debugging woes...
Date: 13 Aug 1996 18:29:26 GMT
Organization: I need to put my ORGANIZATION here.
Lines: 41
Message-ID: <4uqhi6$hn1@news.rwth-aachen.de>
References: <199608122312 DOT JAA05520 AT gbrmpa DOT gov DOT au>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Leath Muller (leathm AT gbrmpa DOT gov DOT au) wrote:
> Ok, I am STILL writing this window stuff, and using a lot of doubly linked
> lists...

> The problem: When I run the program normally, it dies with a seg fault...I
> have found the problem line using the traceback eip, and its:
> 	x = temp->next->x;
> in the subroutine which looks something like:
> 	while (temp->next != NULL)
> 	{
> 		...
> 		x = temp->next->x;
> 		...
> 	}

> I KNOW that the original structures pointer to next is originally
> assigned to NULL when it is added onto the end of a list (this is
> the only time it crashes), but upon execution of the program from
> the command line (win.exe) it crashes. Using printf of the
> temp->next value, I get some weird negative number like -24.

You shouldn't ever get '-24' when printf()ing a pointer value, for two
reasons. First, pointers should be printed using the '%p' format,
which wouldn't ever produce negative output, and second, this value
definitively indicates that the value of 'temp->next' got scrambled
earlier on: no correct pointer in DJGPP can ever point to the unsigned
equivalent of -24. Go and find out where that -24 comes from.

> Anyway, I can't seem to debug it, because when I run the program under
> fsdb and single step, run etc the program, it runs fine!!! 

.... which clearly indicates that you, like every C programmer
sometimes does, managed to screw up the stack or heap management.
Programs changing behaviour when run in a debugger typically do
so because they use the values found in uninitialized storage.
Be sure you initialize all variables before you use them. Additionally,
you might want to compile with '-Wall' and look if any of the places
where gcc warns you about 'value used before it is initialized' might
be the culprit.

Hans-Bernhard Broeker (Aachen, Germany)