bug#22526: 25.0.90; Crash starting gnus

[Eli Zaretskii <eliz@gnu.org>]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Sun, 14 Feb 2016 14:17:19 +0000
> 
> warning: realloc enlarge: VirtualAlloc (00000000001f0000 + 10000, 807) error 87
> 
> Emacs kept working normally at this point, so the latest patch improves things.
> 
> Looking at the running emacs with vmmap (a Microsoft Sysinternals tool),
> I see that the region it was trying to expand the block into was already
> occupied:
> 
> Address            Type          Size   Committed  Private  Blocks  Protection  Details
> 00000000001F0000   Private Data  4      4          4        1       Read/Write
>   00000000001F0000 Private Data  4      4          4                Read/Write
> 0000000000200000   Private Data  2,048  44         44       9       Read/Write  Thread Environment Block ID: 1112
>   0000000000200000 Private Data  1,008                              Reserved    Thread Environment Block ID: 1112

I don't understand how it could have been occupied when the above
message was shown, because of this condition:

      if (VirtualQuery (*var + memInfo.RegionSize, &m2, sizeof(m2)) == 0)
        DebPrint (("mmap_realloc: VirtualQuery error = %ld\n",
		   GetLastError ()));
      /* If there is enough room in the current reserved area, then
	 commit more pages as needed.  */
      if (m2.State == MEM_RESERVE    <<<<<<<<<<<<<<<<<<<<<<<<<<<<
	  && nbytes <= memInfo.RegionSize + m2.RegionSize)
	{

This 'if' says that the region starting at 0x1f0000+0x10000 is in the
"reserved" state, i.e. it cannot be used by any process, including the
Emacs process (Emacs can only start using it after committing the
region, which is exactly what the failed call to VirtualAlloc tried to
do).  Am I missing something?

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.

Thanks.