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

Previous Next

Full log

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

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

> From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
> Date: Sun, 14 Feb 2016 00:44:01 +0100
> Cc: andrewjmoreton <at> gmail.com, 22526 <at> 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.

Previous Next

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