GNU bug report logs - #22526
25.0.90; Crash starting gnus

Previous Next

Full log

View this message in rfc822 format

From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22526 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: bug#22526: 25.0.90; Crash starting gnus
Date: Sun, 14 Feb 2016 22:41:43 +0100

[Message part 1 (text/plain, inline)]

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 <at> gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
> > Date: Sun, 14 Feb 2016 22:04:39 +0100
> > Cc: andrewjmoreton <at> gmail.com, 22526 <at> 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?
>

[Message part 2 (text/html, inline)]

[image.png (image/png, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.