From:	sandmann AT clio DOT rice DOT edu (Charles W. Sandmann)
Subject:	page fault handler problem (fwd)
To:	djgpp AT sun DOT soe DOT clarkson DOT edu (djgpp)
Date:	Fri, 28 May 1993 13:55:53 -0600 (CDT)

Forwarded message:
> From: engdahl AT brutus DOT aa DOT ab DOT com (Jon Engdahl)
> To: djgpp AT sun DOT soe DOT clarkson DOT edu
> Subject: page fault handler problem
> 
> I was working on spawn and make last night (way too late) and ran into
> a problem with a page fault. I have make-3.65 going through the motions
> of doing a simple build (the actual spawnvpe call in my new code in
> turbo_assist is commented out at the moment). After doing several dummy
> compiles, the page fault handler got stuck just after backing out of a
> call to spawn. The bad virtual address was something like e0014xxx. The
> page fault handler was getting to the piece of code that starts with
> "if(vaddr>= 0xf0000000)".  I believe that this is the part that maps
> pages onto the first meg of physical RAM.  The problem is that the page
> fault handler evidently failed to map a valid page, so when it
> returned, the bad reference caused another fault right away, and now we
> are stuck in a loop. I have a hunch that the problem has something to
> do with the "page_[out|in]_everything" that I just completed.

This is the bug that Wonkoo Kim found.  It is fixed in the combined DPMI
+ bug fixes I sent to DJ last night.  The address is legit (and is almost
certainly the transfer buffer).  If you are going to make major hacks to
go32, I suggest you get a copy of this before getting started.

- Raw text -