I see the same block Andrew sees using vmmap and I wonder what buffer is
attached to it.

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().

http://blogs.microsoft.co.il/sasha/2014/07/22/tracking-unusable-virtual-memory-vmmap/
http://forum.sysinternals.com/what-does-vmmap-means-by-unusable-memory_topic25797.html

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724958(v=vs.85).aspx

We have been lucky (or maybe unlucky !) not being hit by this problem
sooner.

Fabrice

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

> > Date: Sun, 14 Feb 2016 18:55:08 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 22526@debbugs.gnu.org
> >
> > It's good to know the patch improves things.  I will push it, and I
> > will also add more debugging printouts to help us understand better
> > what is going on here.
>
> Done.  Please use the changeset in commit 8badf95.  If the error
> message in mmap_realloc gets printed by GDB, please show the data it
> reveals.
>
> Thanks.
>