Mail Archives: djgpp/1997/12/09/11:22:25
> On Mon, 8 Dec 1997, Joshua James Turpen wrote:
>
> > This is a very scary bug. If it does turn out to be a bug in Win95 DPMI,
> > it's really going to hurt DJGPP, since the ___djgpp_hw_exception trick is
> > the basis of signals under DJGPP.
>
> There's a long way before you come to such an extreme conclusion. See
> below.
>
> > static void top_of_vars() {};
> > int tick;
> > int old_sel, old_off;
> > static void bottom_of_vars() {};
>
> Who said you can lock variables in this manner? Functions go into a
> different segment than the variables (CS vs DS), so you cannot lock
> data with this trick. I think what happens is that old_sel and
> old_off wind up not locked, and your interrupt handler touches them.
>
> Please note that the DJGPP FAQ specifically advises to debug hardware
> interrupt handlers by first locking all of the memory with the crt0
> flag (see section 18.9 of the FAQ), because then you *know* everything
> is locked, including the stack. That advice was born out of a lot of
> crashes and other disasters; please use it. Only *after* your handler
> works with everything locked should you move to selectively locking
> only what's needs to be locked.
Ok, I've rewritten the program to use
_crt0_startup_flags =_CRT0_FLAG_LOCK_MEMORY;
It still crashes.
Josh Turpen
44699 AT ef DOT gc DOT maricopa DOT edu
- Raw text -