Date: Mon, 22 Jan 2001 10:12:34 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Tim Van Holder cc: djgpp-workers AT delorie DOT com Subject: RE: Interaction between __dpmi_yield and signals? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.