From:	David Stockton <stockton AT bcm DOT tmc DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Help interpreting a stack trace
Date:	Tue, 29 Apr 1997 09:52:08 -0500
Organization:	Baylor College of Medicine, Houston, Tx
Lines:	21
Message-ID:	<33660B18.49DF@bcm.tmc.edu>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 970429113624 DOT 23034C-100000 AT is>
NNTP-Posting-Host:	ginger.imgen.bcm.tmc.edu
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Eli Zaretskii wrote:
> 
> >  Note also
> > that if I change the declaration of selects timeout argument
> > to static the GPF goes away.  Am I running out of stack space?
> 
> Hmm...  I'm not sure, but the traceback does seem bogus (crnl2lf never
> calls itself, and shouldn't be called by tzload anywa), which might mean
> you are overflowing the stack.
> 
> However, such problems usually yield a Page fault, not GPF.  Is there
> any reason that your program should use large parts of stack space?

I thought of that and stubedit'ed the program and gave it 2M of stack
space but it did not change the result.  This makes me think that one
of the routines is corrupting the stack.  I now just need to track down
which one.  It still seems strange that changing the one declaration
to static fixes it.  Especially since it is not a declaration for an
array or pointer that might be mishandled.  I need to install gdb
(I didn't have the disk space when I installed djgpp version 2). and
look for who clobbers that stack.

- Raw text -