Sorry for the delay with my answer, I'm trying to catch up with this problem. 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 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. 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 ? Fabrice 2016-02-13 11:44 GMT+01:00 Eli Zaretskii : > > Date: Sat, 13 Feb 2016 10:28:37 +0200 > > From: Eli Zaretskii > > Cc: 22526@debbugs.gnu.org > > > > FWIW, I'm not really sure that patch will fix the problem, for 2 > > reasons: (1) the code it fixes should only get executed very rarely, > > if ever; and (2) according to my reading of gap_left, it should have > > touched these addresses just before hitting the segfault. So I > > believe there's some other factor at work here I cannot figure out. > > Answering my own question: #2 above can happen if the gap was already > at the end of buffer text -- in that case, gap_left does nothing > except update the gap position. The values shown in one of the > previous backtraces indicate this is indeed what happened here. And > in that case, line 411 of insdel.c is indeed the first one where the > additional memory allocated by enlarge_buffer_text is touched. > > So it looks like the problem is indeed somewhere in w32heap.c. > > Btw, I see in mmap_malloc a problem similar to the one I tried to fix > with the patch for mmap_realloc: if the call to VirtualAlloc that > commits the reserved memory fails, mmap_malloc won't return NULL as it > should. > > AFAIU, failure to commit reserved memory could happen if the system is > short on physical memory. Are there other reasons? >