Subject: bug#22526: 25.0.90; Crash starting gnus

From: Eli Zaretskii <[email-masked]>
Date: Sat, 13 Feb 2016 18:42:56 +0200

> From: Fabrice Popineau <[email-masked]>
> Date: Sat, 13 Feb 2016 17:08:07 +0100
> Cc: [email-masked], [email-masked]
> 
> Sorry for the delay with my answer, I'm trying to catch up with this problem.

No need to apologize.  Thanks for chiming in.

> First, and about the patch Eli has offered for mmap_realloc(), I would be interested in knowing
> what was the error code at line 718:
> DebPrint (("realloc enlarge: VirtualAlloc error %ld\n",
> GetLastError ()));

I don't think we know that, because I think Andy attached the debugger
only after the crash.  But I sure hope to be wrong ;-)

> I wonder if there is a case where it would fail on the VirtualAlloc() and manage with the mmap_alloc() later.
> I agree than in the case of a failure with VirtualAlloc(), we don't return NULL here, which may be the root
> of further problems.

Yes.  So you agree it's a good idea to commit that patch?

> Second, I don't see the problem in mmap_alloc(): if VirtualAlloc() fails, p is NULL and this is the value returned
> at line 668:
> 
> return *var = p;
> 
> Am I missing something here ?

I thought about the scenario where VirtualAlloc succeeds in the call
with MEM_RESERVE, but fails in the call with MEM_COMMIT.

Please also read the rest of the thread, perhaps my conclusion about
mmap_realloc being the culprit as incorrect.  I just don't see how
else to explain the fact that Emacs asked to enlarge the buffer beyond
64KB, but got a valid pointer to only a 64KB memory region.