From: David Stockton 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: NNTP-Posting-Host: ginger.imgen.bcm.tmc.edu 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 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.