Date: Mon, 23 Apr 2001 13:55:57 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Nimrod A. Abing" <n_abing AT ns DOT roxas-online DOT net DOT ph>
cc: djgpp-workers AT delorie DOT com, broeker AT physik DOT rwth-aachen DOT de,
        Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject: Re: Fixed core dumper in dpmiexcp.c
In-Reply-To: <3.0.1.32.20010423075611.006cf688@wingate>
Message-ID: <Pine.SUN.3.91.1010423135524.25673U-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Mon, 23 Apr 2001, Nimrod A. Abing wrote:

> >> Question to the gurus: is on-the-fly allocation of previously unmapped
> >> pages ('holes') supposed to work, while the client is inside an exception
> >> handler?
> >
> >I think you are mixing unmapped memory with memory that is not paged
> >in.  Untouched memory might be not paged in, but it _must_ be mapped
> >into the program's address space.  That mapping happens when sbrk
> >requests memory from the DPMI host.  In other words, all the memory
> >regions whose handles we have in __djgpp_memory_handle_list[] _must_
> >be mapped into the program's address space at all times.
> >
> >Anyway, referencing an address which doesn't belong to one of the
> >pages mapped into the program's address space will _always_ cause a
> >Page Fault.
> 
> Let's not forget that this problem _does_not_ happen on pure DOS with
> CWSDPMI R5.

I don't see how CWSDPMI is relevant to this issue.  What I was
describing happens with Windows as well.

> Eli, is it possible for the __djgpp_memory_handle_list to
> become corrupt prior to an exception?

A bug can do that.  Otheriwse, __djgpp_memory_handle_list should be
right at all times, since nohing will work if it isn't.  An exception
might invalidate some of the registers, but it does nothing to the
variables which live inside an application, nor to its page tables.