Date:	Mon, 22 Jan 2001 10:12:34 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
cc:	djgpp-workers AT delorie DOT com
Subject:	RE: Interaction between __dpmi_yield and signals?
In-Reply-To:	<NEBBIOJNGMKPNOBKHCGHAEOLCAAA.tim.van.holder@pandora.be>
Message-ID:	<Pine.SUN.3.91.1010122101152.25334E-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 21 Jan 2001, Tim Van Holder wrote:

> gdb shows smalltalk hooking SIGFPE, SIGINT and SIGSEGV at startup.
> This is the hook:
> 
> RETSIGTYPE
> interruptHandler(sig)
>      int	sig;
> {
>   setSignalHandler(sig, SIG_DFL);
> 
>   switch (sig) {
>   case SIGFPE:
>     if (inInterpreter) {
>       setSignalHandler(sig, interruptHandler);
>     } else {
>       kill(getpid(), sig);
>     }
>     return;

I don't know what Smalltalk tries to achieve here, but this is a bad
idea: you cannot simply return from a SIGFPE.

But I don't think that has anything to do with your problem.

> When the delays test is run (the one with the failing SIGALRM),
> it hooks SIGALRM to this:
> 
> RETSIGTYPE
> timeoutHandler(sig)
>      int	sig;
> {
>   setSignalHandler(sig, SIG_DFL);
>   asyncSignal(timeoutSem);
>   timeoutSem = nilOOP;
> }
> 
> I really don't see anything wrong with this though

Is it possible that SIGALRM happens more than once?  If so, the second
time will abort the program, because the above handler resets the
SIGALRM handler to SIG_DFL.

> void
> asyncSignal(semaphoreOOP)
>      OOP semaphoreOOP;
> {
>   IntState oldSigMask;
> 
>   oldSigMask = disableInterrupts(); /* block out everything! */
>   queuedAsyncSignals[asyncQueueIndex++] = semaphoreOOP;
>   setExceptFlag(true);
>   enableInterrupts(oldSigMask);
> }
> 
> Perhaps this disable/enable stuff causes trouble?

What do disableInterrupts() and enableInterrupts() do?  What
``interrupts'' do they disable/enable?

You could also ifdef out this code and see if that helps.

In general, I doubt if this is the problem, since this code runs
_after_ SIGALRM already happened, and it runs from the SIGALRM
handler.  By contrast, the traceback you showed indicates that the
default (i.e. SIG_DFL) handler was called.

> > In any case, if you do run the timer code under GDB, don't forget to
> > say "handle SIGALRM noprint nostop".
> Did. Worked. At least, the program got the SIGALRM and exited with
> a traceback; gdb was unaffected - which is what was supposed to
> happen, I guess.

Yes, with noprint nostop the signal is passed back to the debuggee, and
the result is exactly as if it were not running under the debugger.

- Raw text -