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: Sat, 13 Feb 2016 17:08:07 +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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01177c17774c8d052ba8fe3d X-Trace: ger.gmane.org 1455379793 13967 80.91.229.3 (13 Feb 2016 16:09:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Feb 2016 16:09:53 +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 Sat Feb 13 17:09:46 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 1aUclV-0008KM-EO for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Feb 2016 17:09:45 +0100 Original-Received: from localhost ([::1]:43056 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUclU-0001HC-HD for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Feb 2016 11:09:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUckr-0000cr-N9 for bug-gnu-emacs@gnu.org; Sat, 13 Feb 2016 11:09:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aUcko-0001nv-DU for bug-gnu-emacs@gnu.org; Sat, 13 Feb 2016 11:09:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUcko-0001no-3P for bug-gnu-emacs@gnu.org; Sat, 13 Feb 2016 11:09:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aUckn-0006Hl-Tc for bug-gnu-emacs@gnu.org; Sat, 13 Feb 2016 11:09: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: Sat, 13 Feb 2016 16:09: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.145537971424126 (code B ref 22526); Sat, 13 Feb 2016 16:09:01 +0000 Original-Received: (at 22526) by debbugs.gnu.org; 13 Feb 2016 16:08:34 +0000 Original-Received: from localhost ([127.0.0.1]:39495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aUckL-0006H4-NS for submit@debbugs.gnu.org; Sat, 13 Feb 2016 11:08:33 -0500 Original-Received: from mail-ob0-f175.google.com ([209.85.214.175]:33011) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aUckK-0006Gp-MQ for 22526@debbugs.gnu.org; Sat, 13 Feb 2016 11:08:33 -0500 Original-Received: by mail-ob0-f175.google.com with SMTP id is5so159891367obc.0 for <22526@debbugs.gnu.org>; Sat, 13 Feb 2016 08:08:32 -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=bwydpif4ZDzpLNBttkbZ3XQi4x9ACcEEsTd1eWyilSE=; b=lWPtdv+11tChky0CRhQPGTi/JNiPesCFeh+KVka1AGrWNKduUsl8O4r1PaGE05wQ8P Ql8XxD4FQp+Xtm9ZGUEIXyhVlPrI/q78GFI0876C/6Wtl11ZDUldLSs56AREqd5lHFr9 pLujWCTsE2SxQungRkwdwGuU2vyxaPt8tLKtr40XnGQMPfzomjhx2hN7JF9LXqzxijho B3yvyWnHdfHo/EluSsHtJySFbDefoiVpwSkZEXp4lJhTPArGVPQPVRXS7zVUDngbtPRD 0xo/4Do8/xUnZgqDE7ErSS7unc9HNnb4sm+kt68Tz06PaLuaekHQLbDtTRtISK+ueGke aTmA== 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=bwydpif4ZDzpLNBttkbZ3XQi4x9ACcEEsTd1eWyilSE=; b=Rwvc3DKWa2IGonwOOXU29ccyl/pM/aKaZEAPhP8CAWvxsw7M4glxBinO5M+DyQVmsE JkGjaz3jja8ekKncpzi64zR1AV92dkqeX/NpJ41nbcc/lufXhKlP/y/Zev3A2Smyq5q8 32duFNPDJPKAf5yxDtGBMTPmixx819/aNHoHTwCFZpGtNknfJCip7DKO/4AGrgEzw3Gc 71uWNPLsvB2pptAG3tiRIbltOlAH6snonkhOPmBVKT7Nt07Jj8CBblRPsZKISLS0pl52 ho5tDptChjzcx4zus5ZxYFvHVa1fWaewO0b/3WT4OSAWmmyDjykOQ3qk1M4uPMUAYihX JJpQ== X-Gm-Message-State: AG10YOTa/Lj9A7V2leKNCoxMmfBy33nHHSE4qDoAMWyklPyZwwLjk+g7eCZAkXuM1kre3kHcGkVQYBx92GrKEQ== X-Received: by 10.182.135.132 with SMTP id ps4mr6156851obb.58.1455379707282; Sat, 13 Feb 2016 08:08:27 -0800 (PST) Original-Received: by 10.202.78.131 with HTTP; Sat, 13 Feb 2016 08:08:07 -0800 (PST) In-Reply-To: <83vb5s6gas.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:112974 Archived-At: --089e01177c17774c8d052ba8fe3d Content-Type: text/plain; charset=UTF-8 Sorry for the delay with my answer, I'm trying to catch up with this problem. First, and about the patch Eli has offered for mmap_realloc(), I would be interested in knowing what was the error code at line 718: DebPrint (("realloc enlarge: VirtualAlloc error %ld\n", GetLastError ())); I wonder if there is a case where it would fail on the VirtualAlloc() and manage with the mmap_alloc() later. I agree than in the case of a failure with VirtualAlloc(), we don't return NULL here, which may be the root of further problems. Second, I don't see the problem in mmap_alloc(): if VirtualAlloc() fails, p is NULL and this is the value returned at line 668: return *var = p; Am I missing something here ? Fabrice 2016-02-13 11:44 GMT+01:00 Eli Zaretskii : > > Date: Sat, 13 Feb 2016 10:28:37 +0200 > > From: Eli Zaretskii > > Cc: 22526@debbugs.gnu.org > > > > FWIW, I'm not really sure that patch will fix the problem, for 2 > > reasons: (1) the code it fixes should only get executed very rarely, > > if ever; and (2) according to my reading of gap_left, it should have > > touched these addresses just before hitting the segfault. So I > > believe there's some other factor at work here I cannot figure out. > > Answering my own question: #2 above can happen if the gap was already > at the end of buffer text -- in that case, gap_left does nothing > except update the gap position. The values shown in one of the > previous backtraces indicate this is indeed what happened here. And > in that case, line 411 of insdel.c is indeed the first one where the > additional memory allocated by enlarge_buffer_text is touched. > > So it looks like the problem is indeed somewhere in w32heap.c. > > Btw, I see in mmap_malloc a problem similar to the one I tried to fix > with the patch for mmap_realloc: if the call to VirtualAlloc that > commits the reserved memory fails, mmap_malloc won't return NULL as it > should. > > AFAIU, failure to commit reserved memory could happen if the system is > short on physical memory. Are there other reasons? > --089e01177c17774c8d052ba8fe3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for the delay with my answer, I'm trying to catc= h up with this problem.

First, and about the patch Eli h= as offered for mmap_realloc(), I would be interested in knowing
w= hat was the error code at line 718:
=C2=A0 =C2=A0 =C2=A0DebPrint (("realloc = enlarge: VirtualAlloc error %ld\n",
GetLastError ()));

I wonder if there is a case where it would fail on the VirtualAlloc() and = manage with the mmap_alloc() later.
I agree than in the case of a= failure with VirtualAlloc(), we don't return NULL here, which may be t= he root
of further problems.

Second, I d= on't see the problem in mmap_alloc(): if VirtualAlloc() fails, p is NUL= L and this is the value returned
at line 668:

=
=C2=A0 return *var =3D p;

Am I mi= ssing something here ?

Fabrice



2016-02-13 11:44 GMT+01:00 Eli Zaretskii <<= a href=3D"mailto:eliz@gnu.org" target=3D"_blank">eliz@gnu.org>:
> Date: Sat, 13 Feb 2016 10:28:37 += 0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 22526@debbugs.gnu.org=
>
> FWIW, I'm not really sure that patch will fix the problem, for 2 > reasons: (1) the code it fixes should only get executed very rarely, > if ever; and (2) according to my reading of gap_left, it should have > touched these addresses just before hitting the segfault.=C2=A0 So I > believe there's some other factor at work here I cannot figure out= .

Answering my own question: #2 above can happen if the gap was alread= y
at the end of buffer text -- in that case, gap_left does nothing
except update the gap position.=C2=A0 The values shown in one of the
previous backtraces indicate this is indeed what happened here.=C2=A0 And in that case, line 411 of insdel.c is indeed the first one where the
additional memory allocated by enlarge_buffer_text is touched.

So it looks like the problem is indeed somewhere in w32heap.c.

Btw, I see in mmap_malloc a problem similar to the one I tried to fix
with the patch for mmap_realloc: if the call to VirtualAlloc that
commits the reserved memory fails, mmap_malloc won't return NULL as it<= br> should.

AFAIU, failure to commit reserved memory could happen if the system is
short on physical memory.=C2=A0 Are there other reasons?

--089e01177c17774c8d052ba8fe3d--