From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9901252233.AA13639@clio.rice.edu>
Subject: Re: Exceptions in v2.02
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Mon, 25 Jan 1999 16:33:23 -0600 (CST)
Cc: bill AT taniwha DOT tssc DOT co DOT nz, djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.990125091522.6041D-100000@is> from "Eli Zaretskii" at Jan 25, 99 09:17:20 am
X-Mailer: ELM [version 2.4 PL20]
Content-Type: text
Reply-To: djgpp-workers AT delorie DOT com

> > I believe this is handled by the longjump code.  As I remember it, *all*
> > registers are restored from the longjump buffer, including the seg regs.
> 
> What longjmp?  The one near the end of __djgpp_exception_processor?
> If so, this is a disaster: it means that if I define a non-trivial
> signal handler, it runs entirely on the exception stack (which is
> quite small), because `longjmp' is called after `raise'.
> 
> Imagine that, while the signal handler runs, another signal arrives, and 
> another--soon enough we will overflow the exception stack.
> 
> Charles, is this true?

I can't remember when you run on the locked 8K internal stack.  I think the
original plan was that that only happened when a stack fault was the cause
or when the current SS != the expected stack.  Now, something could have been
changed in this code since 2.00 beta when I wrote it ...

Any change in exception structure might point to the wrong place, or any
messing with the DS alias stuff might break it.

In any case, doing something like a printf when you are on the 8K stack,
which would be possible in some cases, would definitely be a bad thing.