bug#22526: 25.0.90; Crash starting gnus

[Fabrice Popineau]

As vmmap shows it, the next region is unusable.

The reserved region is 4k and the 60k after are lost.

I think it is worth to try that :

diff --git a/src/w32heap.c b/src/w32heap.c

index 69706a3..db14357 100644

--- a/src/w32heap.c

+++ b/src/w32heap.c

@@ -641,12 +641,12 @@ mmap_alloc (void **var, size_t nbytes)

      advance, and the buffer is enlarged several times as the data is

      decompressed on the fly.  */

   if (nbytes < MAX_BUFFER_SIZE)

-    p = VirtualAlloc (NULL, (nbytes * 2), MEM_RESERVE, PAGE_READWRITE);

+    p = VirtualAlloc (NULL, ROUND_UP((nbytes * 2), get_allocation_unit()), MEM_RESERVE, PAGE_READWRITE);

   /* If it fails, or if the request is above 512MB, try with the

      requested size.  */

   if (p == NULL)

-    p = VirtualAlloc (NULL, nbytes, MEM_RESERVE, PAGE_READWRITE);

+    p = VirtualAlloc (NULL, ROUND_UP(nbytes, get_allocation_unit()), MEM_RESERVE, PAGE_READWRITE);

   if (p != NULL)

     {

because running with it, vmmap shows now :

and you see the 64k block is reserved, the first 4k are commited and the next 60k are usable.

Anyway, it is more correct with this patch than without it.

Fabrice

2016-02-14 22:34 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sun, 14 Feb 2016 22:04:39 +0100
> Cc: andrewjmoreton@gmail.com, 22526@debbugs.gnu.org
>
> Also vmmap reports a 4k block committed at 0x1F0000. If I ask vmmap to display free/unusable blocks,
> it reports 0x1F1000 as unusable, size 60k and committed 60k. The problem is that the first block has been
> allocated with 4k, so the next 60k are unusable. We should allocate by block by allocation granularity
> as reported by GetSystemInfo().

Actually... are you saying this explains Andrew's problem in some way?
I cannot see how, because in that case we requested less than 1 page
in the next region, so if even 4KB (one page) was available there, the
call to VirtualAlloc to commit that chunk should have succeeded.  No?