> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sat, 13 Feb 2016 17:08:07 +0100
> Cc: andrewjmoreton@gmail.com, 22526@debbugs.gnu.org
>
> 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.