delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/03/18/03:00:04

Date: Fri, 18 Mar 1994 08:41:44 +0100
From: terra AT diku DOT dk
To: dj AT ctron DOT com
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: In search of the Ctrl-Break bug

Hello!

I went though some debugging yesterday, searching for the Ctrl-Break
bug that sometimes crashes djgpp-compiled programs.

I found one bug for sure, but this is not THE bug: in "dpmisim.asm"
the function `_go_til_stop' is called with the wrong number of
arguments.  I am quite sure that this is not a problem due to the
contents of the stack at call time.

When I run the "ctrlbrk" program under my debugger, and press Ctrl-Break
the program stop approximately 5% of the times.  It *always* stops the
very same place, _int86+72.  This is *exactly* one instruction after 
(dynamically after, that is) the actual "Int xx" instruction.  From this
I deduce, that the single-step flag is on.  I can't actually see this
because that flag is cleared by "mswitch.asm"

Moreover, I observe that the eflags register contains 0x00000248.  ("`How
did 248 get into this,' I hear you cry")  This means "Interrupt Enabled"
and "Zero", but bit three is undefined and supposed (486 at least) to be
zero always.  I conclude that garbage has been loaded into the eflags
register!

Consider this reentry problem: assume that for some reason the extender has
called `memmove', `_memput' or `_memset' in "utils.c"; there are zillions
of reasons to do this.  These functions use the static variable "utils_tss"
and so are not reentrant.  If Ctrl-Break is pressed here, this will lead to
a call to `_memmove' to get the registers into the arena.  This trashes
utils_tss and there is no knowing what happens when the interrupted task
resumes.

Unrelated, in "mswitch.asm" I observe that some of the tasks -- the r-task
for instance -- don't have their NT and T flags cleared.  It this supposed
to be?  Also, it would be much faster to load AL with the bit mask and
use byte sized instruction to clear the flags.

Unrelated also, "dpmisim.asm" seems to be giving the wrong flags register
to the called-back routine, namely the contents of the flags register
*after* the interrupt.

I hope that someone makes sense out of this!

Morten Welinder
terra AT diku DOT dk

- Raw text -


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