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

Previous Next

Package: emacs;

Reported by: Andy Moreton <andrewjmoreton <at> gmail.com>

Date: Mon, 1 Feb 2016 22:16:02 UTC

Severity: normal

Found in version 25.0.90

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 22526 <at> debbugs.gnu.org
Subject: bug#22526: 25.0.90; Crash starting gnus
Date: Sun, 14 Feb 2016 18:55:08 +0200
> From: Andy Moreton <andrewjmoreton <at> 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.




This bug report was last modified 9 years and 91 days ago.

Previous Next


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