Date:	Tue, 24 Apr 2001 14:28:39 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc:	djgpp-workers AT delorie DOT com, Charles Sandmann <sandmann AT clio DOT rice DOT edu>,
	n_abing AT ns DOT roxas-online DOT net DOT ph
Subject:	Re: Fixed core dumper in dpmiexcp.c
In-Reply-To:	<Pine.LNX.4.10.10104241240140.5316-100000@acp3bf>
Message-ID:	<Pine.SUN.3.91.1010424141701.11737G-100000@is>
MIME-Version:	1.0
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

On Tue, 24 Apr 2001, Hans-Bernhard Broeker wrote:

> So yes, it may well be that the code computing the actual size of
> individual memory blocks is wrong, and thus tries to dump unmapped memory.
> As far as I understand the code, it assumes that the whole address range
> spanned __djgpp_memory_handle_list[] is mapped, up to
> __djgpp_selector_limit, with no holes.

I don't have the code handy: does each handle in the list specify its 
starting address and its size?  If so, then why does the code need an 
assumption about the selector limit?  If the handles don't specify their 
actual size, how in tghe world can _any_ code know which pages are and 
which aren't mapped into the program's address space?

It is also possible that the bug is not in the core dumper, but in sbrk, 
where the handle list is maintained.  Wrapping around unisgned values is 
notorious for concealing subtle bugs ;-)

> It computes sizes of individual
> blocks by their distance from the block with the next highest start
> address.

Is this the answer to my question above (about the use of selector 
limit)?  If so, this computation needs to be refined.  But the first 
thing I'd suggest to make sure is that the crashes all happen when a 
block whose ``next highest start address'' suffers from the 4GB 
wrap-around.

> One of the possible reasons why this never causes problems if CWSDPMI is
> used might be if CWSDPMI succeeded the DPMI call in this chunk of code
> inside the core dumper (make_decent_memory_block_list):
> 
>   /* Now try the DPMI call; if it works, we can override the previous 
>    * data; however, I have yet to find a DPMI server that supports it
>    */
>   for (i = 0; i < num_mem_blocks; i++)
>   {
>     __dpmi_meminfo info = { 0, 0, 0 };
>     info.handle = __djgpp_memory_handle_list[i].handle;
>     if (__dpmi_get_memory_block_size_and_base (&info) != -1)
>       if (info.size) mem_block_list[i].size = info.size;
>   }
> 
> Or maybe it's just more well-behaved in nonmoving sbrk() mode than Win9x.

IIRC, CWSDPMI places the arena at 0x10000000, so it might never need the 
wrap-around.

> > It probably depends on what exactly do you do since the bootstrap.
> > Try to record everything you do, each command you invoke and in what
> > order, and reproduce that exactly the next time.
> 
> Will try. But that's a very tiresome procedure, of course :-(

Yes.  You might postpone it until such time as we think we fixed the 
problem, at which time we will need a procedure to see it doesn't happen 
anymore.

- Raw text -