From:	sandmann AT clio DOT rice DOT edu (Charles W. Sandmann)
Subject:	Re: Weird 'unsupported INT' error
To:	mjgreger AT students DOT wisc DOT edu (Michael J. Greger)
Date:	Thu, 13 Jan 1994 20:23:02 -0600 (CST)
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu (DJGPP Mailing List)

>     General Protection Fault at eip=589ac
>     eax=00004f00 ebx=00059150 ecx=e0000000 edx=00000000 esi=00004a9b
>     edi=000049af
>     ebp=7ffff9c0 esp=7ffff9ao cs=d8 ds=0 es=0 fs=0 gs=38 ss=48 cr2=00001440

General protection fault - you are trying to access memory illegally.  Note
that DS, ES, FS selectors are ZERO, which is illegal.  If you run 
symify <progname> right after the failure it will give the names of the 
routines in the call frame traceback, telling you *EXACTLY* where it died.

> I have found a 'fix' for the bug.  If I remove the line with the ind86x
> from the code, NO error!
> 
>     inr.x.di = di_val;
>     int86x(0x10, &inr, &outr, &segs);

This makes sense - int86x should almost NEVER be called from DJGPP.  The
segs must be loaded with real mode segments, which you usually won't have
unless you compute them or allocate them with the _go32 routines.

> The code is doing INT 0x10.  How come the error says 0x0d???

Whatever this call is doing is ILLEGAL.

> I have one idea.  I don't exactly understand the point of the following
> code, but the value it returns is used to compute the di_val for the above
> code.

The transfer buffer address is available from __transfer_buffer or the 
go32 structure defined in <go32.h>  It should be used instead, much more
efficient and less error prone.  The call above should almost certainly be
a call to _go32_dpmi_simulate_int instead.

> Everything worked fin for me until GO32 version 1.11 was released!

Hidden bugs are still bugs!

- Raw text -