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

Previous Next

Full log

Message #53 received at 22526 <at> debbugs.gnu.org (full text, mbox):

From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22526 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#22526: 25.0.90; Crash starting gnus
Date: Sat, 13 Feb 2016 17:08:07 +0100

[Message part 1 (text/plain, inline)]

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 <at> gnu.org>:

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

[Message part 2 (text/html, inline)]

Previous Next

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