From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.bugs Subject: bug#22526: 25.0.90; Crash starting gnus Date: Sun, 14 Feb 2016 10:05:12 +0100 Message-ID: References: <56AFD88B.5040904@gmail.com> <87pow9cc0c.fsf@gnus.org> <83h9hkse78.fsf@gnu.org> <864mdk44q6.fsf@gmail.com> <83mvrcqli1.fsf@gnu.org> <86twlg2e69.fsf@gmail.com> <8360xv9ems.fsf@gnu.org> <8637sz7xmh.fsf@gmail.com> <83io1v7xcd.fsf@gnu.org> <83fuwx7vkv.fsf@gnu.org> <86fuwxk1l1.fsf@gmail.com> <837fi96mkq.fsf@gnu.org> <83vb5s6gas.fsf@gnu.org> <83d1s05zov.fsf@gnu.org> <83r3ggz2dt.fsf@gnu.org> <83oabjzvry.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bfeb70ad278d9052bb733a2 X-Trace: ger.gmane.org 1455440780 11698 80.91.229.3 (14 Feb 2016 09:06:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Feb 2016 09:06:20 +0000 (UTC) Cc: 22526@debbugs.gnu.org, andrewjmoreton@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Feb 14 10:06:12 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aUsd9-0004O3-Fs for geb-bug-gnu-emacs@m.gmane.org; Sun, 14 Feb 2016 10:06:11 +0100 Original-Received: from localhost ([::1]:48897 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUsd8-0001NL-3a for geb-bug-gnu-emacs@m.gmane.org; Sun, 14 Feb 2016 04:06:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUsd3-0001Kd-3V for bug-gnu-emacs@gnu.org; Sun, 14 Feb 2016 04:06:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aUscz-0001Y2-SV for bug-gnu-emacs@gnu.org; Sun, 14 Feb 2016 04:06:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUscz-0001Xy-P6 for bug-gnu-emacs@gnu.org; Sun, 14 Feb 2016 04:06:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aUscz-0005Ej-JX for bug-gnu-emacs@gnu.org; Sun, 14 Feb 2016 04:06:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Fabrice Popineau Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 14 Feb 2016 09:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22526 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22526-submit@debbugs.gnu.org id=B22526.145544074020103 (code B ref 22526); Sun, 14 Feb 2016 09:06:01 +0000 Original-Received: (at 22526) by debbugs.gnu.org; 14 Feb 2016 09:05:40 +0000 Original-Received: from localhost ([127.0.0.1]:38495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aUscd-0005EB-Lh for submit@debbugs.gnu.org; Sun, 14 Feb 2016 04:05:39 -0500 Original-Received: from mail-ob0-f180.google.com ([209.85.214.180]:33916) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aUscb-0005Dx-L6 for 22526@debbugs.gnu.org; Sun, 14 Feb 2016 04:05:38 -0500 Original-Received: by mail-ob0-f180.google.com with SMTP id wb13so177135220obb.1 for <22526@debbugs.gnu.org>; Sun, 14 Feb 2016 01:05:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Wd7jG9wlME/ijcz99G1aikhAZEGc73clZEI/LB1Pjpg=; b=mi4ITYkjVD5rQucmwsTq1zwkPSvVFg+qbXia06q5wYpsMXG23fzMcFWn79vI01NHuR sJb4mkDfaLbg2amxC2Bhv4u61ajmdEewKeLiPLbvaxGYOymtAH+GOTIqqN20SaBAM3+O 0X3gZjRnGIOyQfIXHVkiZVu+KeoFhaY+GS6waeJaYtN/0xvwCPp2cLTjoS8ysgLtHACn QKVO+REE86X9kSNceJj5WEV1EM6ocvPzkWkDSM3+5ZyAJ7j+N6UVOO8atvB4IfzifJWN mr6WIFeWshyGhhnPPM2pvNg91VZva5C+hdJX2fT31WMPKtv7Td+JzOSrMDwY7C+DeURD 4CSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Wd7jG9wlME/ijcz99G1aikhAZEGc73clZEI/LB1Pjpg=; b=UNhQ9NhxenJhd14g3U5+YGLjH8W2zaIM7j2fDYGlMspVHwO4mBqRHtdzCpnsZ4X0Os IDWTRUxHZG66n8fOhWwuHCLdSUjDHEFroKRvwM7AUctv4qSSybIxoa2fcaARDftQP7f0 HEB5kmQhWt4C2NQ1r9J77VyL5+2yaFFd7HmUqlsS2Jwv3JtZ01Ep/S9wqrbMm1mI2MLV BM1zFQwbV4oTaoD6gjetO3h4NJsJndYMxcbQj50PUTIOJLok1KW4Ct8bPAZkFnQ2yW1V CFUplSIUscLirbmyauixOtw0qiYjxIi0wVeQDhu2C1376N94kt5LJYtVdL8Cc5GT1tJo ABiw== X-Gm-Message-State: AG10YOSQYIgaJGknFUHMpmLKEaRNGIVzxzLDncTfpV+p2VC+9rf1CAsYT/ii8zEussooO8DQ4btOwNy0JKAurw== X-Received: by 10.182.51.138 with SMTP id k10mr980437obo.76.1455440731992; Sun, 14 Feb 2016 01:05:31 -0800 (PST) Original-Received: by 10.202.78.131 with HTTP; Sun, 14 Feb 2016 01:05:12 -0800 (PST) In-Reply-To: <83oabjzvry.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:113009 Archived-At: --047d7bfeb70ad278d9052bb733a2 Content-Type: text/plain; charset=UTF-8 2016-02-14 6:49 GMT+01:00 Eli Zaretskii : > > From: Fabrice Popineau > > 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 --047d7bfeb70ad278d9052bb733a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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.c= om, 22526@debbugs.gnu.org<= br> >
>=C2=A0 What I'm worried about is something else: the code is writte= n under
>=C2=A0 the assumption that *var is the base address of the allocation, = which
>=C2=A0 is why we use *var + memInfo.RegionSize to get to the next regio= n.
>=C2=A0 But if *var is not the base address, this is wrong, and we shoul= d use
>=C2=A0 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 so= me buffer b.
> Is there somewhere a good reason to do that ?

No, there isn't.=C2=A0 But how sure are we that the address Virt= ualAlloc
returns to us when we commit is always the base address of the region?
<= /blockquote>

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

Return val= ue

If the function succeeds, the return value is t= he base address of the allocated region of pages.
If the function= fails, the return value is NULL. To get extended error information, call G= etLastError.

=C2=A0
= =C2=A0=C2=A0 (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.=C2=A0
=C2=A0
Btw, what exactly is the difference between memInfo.BaseAddress and
memInfo.AllocationBase?=C2=A0 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 sho= uld use AllocationBase.

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

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

Will do if nothing else come up.

>=C2=A0 > The error codes from VirtualAlloc() here are crucial.
>
>=C2=A0 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.=C2=A0 I'd actually expect ERROR_INVALID_ADDRESS in that c= ase, but
this is not explicitly documented anywhere.

Something I refer t= o when I need to understand the inner workings of the win32 API is the sour= ce 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
--047d7bfeb70ad278d9052bb733a2--