www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2001/07/15/11:38:10

Date: Sun, 15 Jul 2001 18:34:39 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: "Matthew Conte" <matt AT conte DOT com>
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

> From: "Matthew Conte" <matt AT conte DOT com>
> 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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019