From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10104242208.AA18766@clio.rice.edu>
Subject: Re: Fixed core dumper in dpmiexcp.c
To: broeker AT physik DOT rwth-aachen DOT de (Hans-Bernhard Broeker)
Date: Tue, 24 Apr 2001 17:08:24 -0500 (CDT)
Cc: djgpp-workers AT delorie DOT com (djgpp workers list),
        n_abing AT ns DOT roxas-online DOT net DOT ph
In-Reply-To: <Pine.LNX.4.10.10104241925100.5316-100000@acp3bf> from "Hans-Bernhard Broeker" at Apr 24, 2001 07:28:00 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

> > > From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> > > Date: Tue, 24 Apr 2001 09:40:12 -0500 (CDT)
> > > 
> > > Without the size of each block you can't reliably do a dump.  To get the
> > > size of each block we would have to add this to the sbrk() code
> > 
> > Does catching Page Faults during dumping and longjmp'ing to dump the
> > next page sound like a possible band-aid?
> 
> Hmm... sounds like jumping to the next block would make more sense. I.e.
> assume that it's only the size we got wrong, but there's still no hole
> inside the block represented by one entry in the
> __djgpp_memory_handle_list[].

Agreed on jumping to next block.  But you also need to "fix" the assumed 
length someplace (already written to the dump?)

This is also making the dump a much riskier thing - we've already had 
one exception and now we plan to potentially cause a bunch more while
dumping on an environment with unknown stability.

You may also dump several additional MB's of memory which don't belong to
you.

We really just need to add the memory block lengths someplace.  Maybe a
good incentive to re-write sbrk() in C :-)