Date: Tue, 29 Apr 1997 11:37:32 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: David Stockton <stockton AT bcm DOT tmc DOT edu>
cc: djgpp AT delorie DOT com
Subject: Re: Help interpreting a stack trace
In-Reply-To: <335E1689.766D@bcm.tmc.edu>
Message-ID: <Pine.SUN.3.91.970429113624.23034C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Wed, 23 Apr 1997, David Stockton wrote:

> I am working on a library of routines and a small test program
> (about 30 lines; the call a routine, print a message type)
> dies with the following stack trace.  Since it dies in a standard
> library routine I was not sure how to track it down.

The usual way: get the library sources, compile them with -g and step
into them with a debugger.

>  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?