Date: Sun, 15 Jul 2001 18:34:39 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: "Matthew Conte" Message-Id: <3405-Sun15Jul2001183438+0300-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9 CC: djgpp AT delorie DOT com In-reply-to: <001d01c10d33$d7e6b9c0$e33e1d18@nycap.rr.com> (matt@conte.com) Subject: Re: '9x and raise in interrupt service routines References: <001d01c10d33$d7e6b9c0$e33e1d18 AT nycap DOT rr DOT com> Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Matthew Conte" > Date: Sun, 15 Jul 2001 09:41:24 -0400 > > i have a custom keyboard handler installed via > _go32_dpmi_set_protected_mode_interrupt_vector, so the standard SIGINT > does not get handled for CTRL-C/CTRL-BREAK. i'd like to be able to > handle the keystrokes in my own handler by calling raise(SIGINT), but > this causes the dreaded windows "This program has caused an illegal > operation..." dialog box to pop up and close my traceback dosbox. You should post more details about what you do, but it sounds like you are trying to call `raise' from a hardware interrupt handler. If so, you have just discovered why the DJGPP signal-handling machinery doesn't do that: it is bound to get you in trouble. For starters, your interrupt handler is called with only the CS selector being valid; all the other registers (DS, ES, FS, GS) might be invalid, and SS points to a special locked stack, which is small and thus inappropriate for running general-purpose application code. Moreover, the default SIGINT handler tries to unwind the stack, which is one-way ticket to disaster when the stack isn't yours. And there are other possible complications, depending on what your code does, exactly. In other words: don't do that! > i'm trying to handle SIGINT correctly to use gdb to track down an > infinite loop somewhere in my code. without handling SIGINT, my > custom keyboard handler prevents SIGINT from ever occurring, so i can > never break out of the infinite loop. Why don't you simply chain to the previous keyboard handler? That would do what you want, and do it safely, because the previous handler is the one installed by the startup code, which generates SIGINT in any normal DJGPP application.