[Top][All Lists]

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

bug#22526: 25.0.90; Crash starting gnus

From: Eli Zaretskii
Subject: bug#22526: 25.0.90; Crash starting gnus
Date: Sat, 13 Feb 2016 18:42:56 +0200

> From: Fabrice Popineau <address@hidden>
> Date: Sat, 13 Feb 2016 17:08:07 +0100
> Cc: address@hidden, address@hidden
> 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.

reply via email to

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