From: Charles Terry <cterry AT plinetl DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Seg fault
Date: Thu, 05 Feb 1998 20:16:59 -0800
Organization: All USENET -- http://www.Supernews.com
Lines: 30
Message-ID: <34DA8EBB.38E0@plinetl.com>
References: <34DA8954 DOT 320 AT ee DOT net> <34DA89A8 DOT A51 AT ee DOT net>
Reply-To: cterry AT plinet DOT com
NNTP-Posting-Host: 25121 AT 207 DOT 174 DOT 3 DOT 214
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

David Mikesell wrote:
> 
> ...I'm also using Allegro 3.0
> 
> >
> > I'm using djgpp 2.01 on dos 6.22 and am trying to work through
> > a particularly nasty seg fault bug.  I will purposely keep
> > the problem statement general here, but will be happy to
> > drill down to the source if nobody can point me in the right
> > direction to begin looking.
> >
> > I get the seg fault immediately after returning from a function
> > that allocates memory...I can't seem to narrow the bug down to
> > an offending pointer reference or a free() of a NULL pointer, etc.
> > None of the malloc()'s returns a NULL pointer.  Any ideas
> > on where to start looking?
> >
> > --
If you crash on a return from malloc chances are that malloc is
overwriting the stack.  This situation can occcur when another part of
your own code overwrits part of mallocs internal tables.  Its a tough
bug because the overwrite could have happend somewhere that seems
totally unrelated.
My own solution to this was to get the malloc source and compile it with
debugging on. Then step through it at the point of the error and check
the "bucket" it uses for not pointer type values.  Then get the address
of the corupted value and put a watch on it and restart and step thru
the program again watching fo when the pointer is overwritten.
Sorry for such a complex answer but hope it helps.
Charles Terry