From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#49261: Segfault during loadup Date: Wed, 14 Jul 2021 17:24:37 -0500 Message-ID: <33801f54-3794-d98c-54c3-c67ce53ec6c0@cs.ucla.edu> References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> <83bl79b17n.fsf@gnu.org> <835yxgc1pm.fsf@gnu.org> <83wnpvag6z.fsf@gnu.org> <5608bf0a-7211-73a9-690f-c869a1cb3c9d@cs.ucla.edu> <83o8b7a5ow.fsf@gnu.org> <83eec1843o.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------6132E8812C143D05C8BD6D80" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39661"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Cc: larsi@gnus.org, 49261@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 15 00:25:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m3nJW-000A0t-VK for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Jul 2021 00:25:11 +0200 Original-Received: from localhost ([::1]:46586 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m3nJV-00008i-Tq for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 14 Jul 2021 18:25:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51604) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m3nJO-00008Y-Dr for bug-gnu-emacs@gnu.org; Wed, 14 Jul 2021 18:25:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34530) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m3nJO-0007cI-5b for bug-gnu-emacs@gnu.org; Wed, 14 Jul 2021 18:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m3nJN-0007Y5-SB for bug-gnu-emacs@gnu.org; Wed, 14 Jul 2021 18:25:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 14 Jul 2021 22:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49261 X-GNU-PR-Package: emacs Original-Received: via spool by 49261-submit@debbugs.gnu.org id=B49261.162630148728989 (code B ref 49261); Wed, 14 Jul 2021 22:25:01 +0000 Original-Received: (at 49261) by debbugs.gnu.org; 14 Jul 2021 22:24:47 +0000 Original-Received: from localhost ([127.0.0.1]:46076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3nJ8-0007XV-LK for submit@debbugs.gnu.org; Wed, 14 Jul 2021 18:24:46 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52554) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3nJ7-0007XG-7o for 49261@debbugs.gnu.org; Wed, 14 Jul 2021 18:24:46 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5ACE31600B2; Wed, 14 Jul 2021 15:24:39 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id qtKkR--N47eU; Wed, 14 Jul 2021 15:24:38 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7AC131600BB; Wed, 14 Jul 2021 15:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UqQByrT1OQyk; Wed, 14 Jul 2021 15:24:38 -0700 (PDT) Original-Received: from [192.168.0.205] (ip72-206-1-93.fv.ks.cox.net [72.206.1.93]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 18AF61600B2; Wed, 14 Jul 2021 15:24:38 -0700 (PDT) In-Reply-To: <83eec1843o.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:209973 Archived-At: This is a multi-part message in MIME format. --------------6132E8812C143D05C8BD6D80 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/14/21 7:36 AM, Eli Zaretskii wrote: > You are saying that there's some fundamental difference between > > INT_MAX + 1 > > and > > (USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_MAX) Yes there's a fundamental difference. INT_MAX + 1 has a signed integer overflow that violates the C standard. Obviously GCC should diagnose it. The other expression conforms to the C standard and there is no error or overflow there. There's no reason -Woverflow should provoke a diagnostic for it. > Or between an expression 'x = FOO' and 'mask = BAR'? I don't know what x, mask, FOO, and BAR refer to. > the warning was valid, as the > assignment loses significant bits. I originally wrote it as "uintptr_t mask = VALMASK;" because I would rather avoid C casts when possible (they're too powerful and allow too many bugs to go undetected). I dislike the workaround that I installed because of (a) its unnecessary cast and (b) the lack of clarity that it's intended that we want to discard any bits outside UINTPTR_MAX ((b) was a problem with my original code too). To try to fix both (a) and (b) I installed the attached further patch. It is a bit more verbose than what C requires, but the verbosity should help explain that masking with UINTPTR_MAX is intended, and the verbosity shouldn't hurt efficiency. --------------6132E8812C143D05C8BD6D80 Content-Type: text/x-patch; charset=UTF-8; name="0001-Pacify-gcc-Woverflow-more-clearly.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Pacify-gcc-Woverflow-more-clearly.patch" >From 0afbde4e68c1161a54f9593ecb5b66fe42aa0de4 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 14 Jul 2021 17:10:06 -0500 Subject: [PATCH] Pacify gcc -Woverflow more clearly * src/alloc.c (mark_maybe_pointer): Make it clearer that ANDing with UINTPTR_MAX is intended. Omit a now-unnecessary cast. --- src/alloc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/alloc.c b/src/alloc.c index ee3fd64a00..8edcd06c84 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -4764,7 +4764,9 @@ mark_maybe_pointer (void *p, bool symbol_only) from Emacs source code, it can occur in some cases. To fix this problem, the pdumper code should grok non-initial addresses, as the non-pdumper code does. */ - void *po = (void *) ((uintptr_t) p & (uintptr_t) VALMASK); + uintptr_t mask = VALMASK & UINTPTR_MAX; + uintptr_t masked_p = (uintptr_t) p & mask; + void *po = (void *) masked_p; char *cp = p; char *cpo = po; /* Don't use pdumper_object_p_precise here! It doesn't check the -- 2.25.1 --------------6132E8812C143D05C8BD6D80--