bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22526: 25.0.90; Crash starting gnus


From: Fabrice Popineau
Subject: bug#22526: 25.0.90; Crash starting gnus
Date: Sat, 13 Feb 2016 17:08:07 +0100

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 <eliz@gnu.org>:
> Date: Sat, 13 Feb 2016 10:28:37 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]