Mail Archives: djgpp-workers/2001/04/06/14:19:06
> Yes: it crashes on this instruction:
>
> 0x8ec1 <big_move+7>: repz movsl %ds:(%esi),%es:(%edi)
>
> > Page fault at eip=00008e91, error=0004
> > eax=00000000 ebx=00004000 ecx=00001000 edx=0000f620 esi=00030000 edi=0000f620
> > ds: sel=00ff base=830bf000 limit=002f5fff
> >
> > Call frame traceback EIPs:
> > 0x00008e91 ___dj_movedata+33
>
> Since this is a Page Fault, and the error code is 4, the primary
> suspect is the value of ESI, which points to the address where the
> data is read from.
> Charles, is it possible for another program, such as an antivirus,
> cause a Page Fault by smething its code does, but have Windows abort
> our program instead?
On the basis of the DPMI memory blocks, I would expect this address to
be valid (it's a 192Kb offset from the base; it's possible the DPMI
memory block size/address chain is buggy in our code - or the dumper's
interpretation of it - but I would hope unlikely). Since it is on a
64K boundary it could be that the size/bases of the blocks are not being
recorded/interpreted properly and this might the problem here. A dump
of the memory handles would probably be useful information here.
I'd like a simple experiment here - set the crt0 flag to deadbeef or zero
the memory. When we dump the memory we are also dumping memory we may
have not touched yet. It's possible that the antivirus software somehow
changes Window's behavior in this case (windows bug? Uninitizlized behavior?
on purpose?)
> In other words, what could be a reason for a program to get a Page
> Fault if the instruction is a perfectly valid one and all the
> registers hold valid values?
The DPMI provider may internally get a page fault if the page hasn't be
committed to memory yet, or is paged out into the page file. It should
transparently handle it, but for some reason it doesn't in this case and
sends the exception to our handler. Maybe also a byproduct of the
other installed software, but hard to tell.
- Raw text -