bug#22526: 25.0.90; Crash starting gnus

[Fabrice Popineau <fabrice.popineau@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]

2016-02-14 6:49 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > 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?
>

This what the documentation says.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).aspx

Return value

If the function succeeds, the return value is the base address of the
allocated region of pages.
If the function fails, the return value is NULL. To get extended error
information, call GetLastError.



>    (I also tried to google for failure to
> commit reserved memory, but didn't find anything that looked like our
> case.)
>
> I did the same.


> 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.
>
>
Same question here.
Re-reading the documentation, I would understand it as :
- BaseAddress is the adress that we passed to VirtualQuery, rounded down to
the beginning of the page
- AllocationBase is the start of the bloc of pages that we have committed
previously.
So we should use AllocationBase.

Another thing I wonder: could pages be in a state MEM_RESERVE | MEM_COMMIT?
I hope not.



> > 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.
>

Something I refer to when I need to understand the inner workings of the
win32 API is the source code for ReactOS:
http://doxygen.reactos.org/d2/d2c/virtual_8c_a39ad5f8f1a5214f4874171695ab2bd6b.html#a39ad5f8f1a5214f4874171695ab2bd6b
(for example).
Not ideal, and it doesn't mean the MS thing works the same way, but at
least it allows to understand some things.

Fabrice

[-- Attachment #2: Type: text/html, Size: 4900 bytes --]