Mail Archives: djgpp/1996/01/25/06:37:32
> I tried it with the following program, but every time I run it, there is a
> Page fault. I am using DJGPP V2Beta4 and CWSDPMI Beta9. Where is the error.
It's a bug in your program. Lets first look at the register listing you
provided:
> Page fault cr2=10060fe7 in RMCB at eip=fe7; flags=3002
> eax=00000000 ebx=00002396 ecx=00000000 edx=00050e67 esi=0001944e edi=0000a230
> ebp=0004a298 esp=0000347c cs=e7 ds=3b es=f7 fs=33 gs=ff ss=33 error=0004
Note that the flags show interrupts are disabled, CS is LDT and near ES
(meaning it's in your 32-bit code area). The EIP is less than 0x10a8, so
is clearly wrong (this page fault is due to reading the NULL page). The
CR2 value confirms this (the low 64K bits are identical, this trace came
from being run in the debugger or in some other nested DJGPP image). The
SS:ESP is on the locked stack.
An examination of your code shows you passed the address of _new_int80
directly to __dpmi_allocate_real_mode_callback, but this is a C routine
and not an assembly wrapper. Since the PM routine must manipulate the
RMCB structure and do IRET to return, this is the bug. The C routine
does a near return (instead of a far one via IRET) loading an EIP for
a different selector.
You need to use one of the wrapper routines, probably something like
_go32_dpmi_allocate_realmode_callback_iret (in dpmi.h). But! This
routine is implemented in gormcb.c and has a locking bug - see the
patch posted 3 days ago to fix this.
- Raw text -