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

Previous Next

Full log

View this message in rfc822 format

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

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

Previous Next

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