Date:	Wed, 12 Oct 1994 17:05:05 -0400 (EDT)
From:	Long Doan <ldoan1 AT mason1 DOT gmu DOT edu>
Subject:	Re: Segmentation violations
To:	"D.R.Tauritz" <dtauritz AT wi DOT leidenuniv DOT nl>
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu

On Tue, 11 Oct 1994, D.R.Tauritz wrote:

> Now my interrupt routine is called... and the more subtle bugs arise :-(
> Every time the user presses a key an interrupt is generated. The interrupt
> routine simply increases a counter. On return of the interrupt the value of
> the counter is displayed on the screen. The output should obviously be:
> Alas, the output is for example:
>   tics=0
>   tics=0
...
>   tics=406
>   tics=408
>   Unsupported
>   INT 0x0d
>   tics=410
>   Segmentation violation in pointer 0xf000a001 at a00:1
>   eax=00003093 ebx=00000000 ecx=0000019e edx=00000020 esi=0002a61c
>   edi=00004150 ebp=00000000 esp=12102cbc cs=a00 ds=37f es=2cbc fs=12c2
>   gs=2cbc ss=ca57 cr2=0000a001
>   Call frame traceback EIPs:
>     0x00000001
  Did that happen when you press 'q' ? Either ways, we ran into the same 
problem a little while ago, trying to install our timer interrupt. We 
found out that the fault was caused by a bug in the _go32_..._chain_... 
routine, so we bypassed go32 calls altogeter, and modified the IDT 
directly. One more thing, in your ISR, you should jump 
directly to the old ISR (This only works if you bypass the _go32... 
calls.) The 0 0, 2 2... happens, IMHO, because you're spending too much 
time in real mode (waiting for the key,) so when you recieved the IRQ, 
you jumped back to protected mode, inc the variable (which is not 
reflected) At that time, the protected IRQ is made, and your ISR do that 
again, so 0 -> 2. That goes on... You should also avoid calling DOS 
function inside ISR, because that'll drop to real mode (i.e. calling 
printf ().) 
Hope that helps,
Long.

---------------------
ld AT netrix DOT com
ldoan1 AT mason1 DOT gmu DOT edu

- Raw text -