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: Fabrice Popineau
Subject: bug#22526: 25.0.90; Crash starting gnus
Date: Sun, 14 Feb 2016 10:05:12 +0100



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

reply via email to

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