bug#22526: 25.0.90; Crash starting gnus

[Fabrice Popineau <fabrice.popineau@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2103 bytes --]

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 :

[image: Images intégrées 1]

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?
>

[-- Attachment #1.2: Type: text/html, Size: 3040 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 158886 bytes --]