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: Eli Zaretskii
Subject: bug#22526: 25.0.90; Crash starting gnus
Date: Sun, 14 Feb 2016 07:49:21 +0200

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sun, 14 Feb 2016 00:44:01 +0100
> Cc: andrewjmoreton@gmail.com, 22526@debbugs.gnu.org
> 
>  What I'm worried about is something else: the code is written under
>  the assumption that *var is the base address of the allocation, which
>  is why we use *var + memInfo.RegionSize to get to the next region.
>  But if *var is not the base address, this is wrong, and we should use
>  memInfo.BaseAddress instead, I think. WDYT?
> 
> Yes, that should probably be more correct.
> But that would also mean someone has changed b->text->beg for some buffer b.
> Is there somewhere a good reason to do that ?

No, there isn't.  But how sure are we that the address VirtualAlloc
returns to us when we commit is always the base address of the region?
It could theoretically return any page-aligned address within the
region we previously reserved, no?  So I added debugging printouts to
actually show those data.  (I also tried to google for failure to
commit reserved memory, but didn't find anything that looked like our
case.)

Btw, what exactly is the difference between memInfo.BaseAddress and
memInfo.AllocationBase?  The MSDN documentation describes both using
the same words in different order, so it's hard to understand.

> The mmap_alloc() and mmap_realloc() are called each at one place only in 
> buffer.c .
> Maybe we should try to assert *var == memInfo.BaseAddress and see if it 
> breaks.

Will do if nothing else come up.

>  > The error codes from VirtualAlloc() here are crucial.
> 
>  The error is ERROR_INVALID_PARAMETER (87), as Andy just reported.
> 
> Weird. There is a good chance that *var is wrong and you are right.

Maybe.  I'd actually expect ERROR_INVALID_ADDRESS in that case, but
this is not explicitly documented anywhere.





reply via email to

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