From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#46988: 28.0.50; Documenting and verifying assumptions about C code not calling quit or GCing Date: Mon, 8 Mar 2021 19:57:07 +0000 Message-ID: References: <875z21mnyh.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28322"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46988@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 08 20:58:54 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 1lJM1m-0007F6-8B for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Mar 2021 20:58:54 +0100 Original-Received: from localhost ([::1]:33900 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJM1l-0001Js-9N for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Mar 2021 14:58:53 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56528) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJM0v-0000ZJ-UL for bug-gnu-emacs@gnu.org; Mon, 08 Mar 2021 14:58:01 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33361) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJM0v-0001zx-Kp for bug-gnu-emacs@gnu.org; Mon, 08 Mar 2021 14:58:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lJM0v-0001J4-JC for bug-gnu-emacs@gnu.org; Mon, 08 Mar 2021 14:58:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Mar 2021 19:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46988 X-GNU-PR-Package: emacs Original-Received: via spool by 46988-submit@debbugs.gnu.org id=B46988.16152334715003 (code B ref 46988); Mon, 08 Mar 2021 19:58:01 +0000 Original-Received: (at 46988) by debbugs.gnu.org; 8 Mar 2021 19:57:51 +0000 Original-Received: from localhost ([127.0.0.1]:44907 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJM0k-0001Id-SU for submit@debbugs.gnu.org; Mon, 08 Mar 2021 14:57:51 -0500 Original-Received: from mail-oo1-f41.google.com ([209.85.161.41]:32828) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJM0j-0001IO-8V for 46988@debbugs.gnu.org; Mon, 08 Mar 2021 14:57:49 -0500 Original-Received: by mail-oo1-f41.google.com with SMTP id z22so2484802oop.0 for <46988@debbugs.gnu.org>; Mon, 08 Mar 2021 11:57:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sTrCfs1TcEpoeZekyEQZjPGP+H2MltmncqaXT2G0Li8=; b=hs3+V74EwwpkJmJh9VWTvPkj9pwbU5QbhbMbfoWu0aKkt/thbKmVioW/dfzPK5ixQZ CRW3tZvDY/CaEvtxvlb+duQcFWDwmdmuLOrrCQlXFf6RPXlF1H25dZHSTSnGXFklJM5c XF/6q+HpILpQ2mIBwL9FyFc7UfSA8r77n8J2fHPEeZF66x6LI+ABr3empbLcl07YYT12 CWLznksujK0EHzjZP6dVcsICqM6eQG0YmuvuyMZl7a237YjOTpiEkM2/Tg/yiagJIAd6 4myf2JQbLfnOy/1QYJ1wVJD/EmV3e8mnot2ERNbaHKqYVhvUhvlIwcQbj/lbdL/htUST 4OEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sTrCfs1TcEpoeZekyEQZjPGP+H2MltmncqaXT2G0Li8=; b=aN8wRiwEfCyqL5XU4iD1x5f9mp/HR52e7VT8NZ+uJLSA+22Mr0a7g13TQgekj4dz5y w+41KHEfuofGxBHdHR6YhQ4TvJm3JepQTFAieRPiG7F8cgqTRN2LEsTG95hnm9G8MJWN BKg+EaO5DOsrzUKZYRpoBuZzijVCS6vqRd1eOCgAF18x5T1wmr4Y0ibCUs2joq7oqE72 vtyWQDa6mZ/1LUXMrMtxff9Ru7No2fk8RqH8apaaDl9F5j18iXJByjAgMertYbvjMEGw /nFUxPZ71BOfhrHsaLJC6z0kLv97MkmnmZNr3aKuj0NPWH3SS8vdOpuNPDvoKeMOo6V5 tkjg== X-Gm-Message-State: AOAM533M9xb34au1Dq40WG86T3Uk9cTAAjcboabQs61TZxH2UV53ijZu Zk/NmL6uuRH4HsnWYyRNe1seg+yUZ+iYemX/GVY= X-Google-Smtp-Source: ABdhPJx4B7hrPevLhpvx5P5yEiLTgZu2jyApuCnE/TkydDyiTHUqhPBaEfDqlA7zdCRm1w0aPK3ixLy4vDaDPzeO+FU= X-Received: by 2002:a4a:2511:: with SMTP id g17mr20155100ooa.22.1615233463497; Mon, 08 Mar 2021 11:57:43 -0800 (PST) In-Reply-To: <875z21mnyh.fsf@gnus.org> 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:201879 Archived-At: On Mon, Mar 8, 2021 at 7:42 PM Lars Ingebrigtsen wrote: > Pip Cet writes: > > > Patch attached. It assumes the standard stack growth direction, and > > that __builtin_frame_address (0) is available and works. Uses GCC's > > __attribute__ ((cleanup (...))). > > > > My point here is that the technical implementation isn't the problem, > > the question is whether we're disciplined enough to run with checking > > enabled and react to bug reports about the fatal error being thrown. > > This is something that comes up again and again, so having > infrastructure to getting feedback faster on this stuff sounds like a > good idea to me. > > Even better would be to have build-time warnings, but I guess that's > pretty much impossible? It would be very easy if we could categorize our functions into "don't call this unless you can accept GC" and "I won't GC", but there's a third category, "depending on my arguments, I may or may not call GC" (and, of course, a fourth category, "uncategorized"). It's easy to warn about category 1 functions being called from category 2 functions, but category 3 ruins everything. I'm very impressed with gcc's -fanalyzer (in conjunction with -flto) If you have 20 GB of RAM and 15 minutes to spare, you can get it to find a few places in the Emacs sources that really do look suspicious and should be fixed to more obviously not dereference NULL. Essentially, it does a lot of hard work trying to prove your code is okay; but, if it can't, it will warn even though it might be (and, in the case of Emacs, is) wrong. So "all" we'd have to do is to teach it about some category 1 functions, some category 2 functions, and have it prove there's no valid control flow from the second to the first. If it can't, we just might have to accept that our arguments are not obvious enough, and make them explicit enough for the analyzer to understand. But I haven't figured out how to do that, yet. My suspicion is the analyzer works on local variables and ignores the state of global variables, and our state vars would have to be global. And I realize I'm poking a hornet's nest, but what this really is is dynamic scope, which might be easier for the analyzer to grok than general global variables... hmm. In summary, I think we can install the run-time check, and when the analyzer is ready, we'll automatically get compile-time warnings! Even though it might require a terabyte of RAM! I also like the way we can build specbind-free dynamic C bindings using stack structures, global variables, __attribute__((cleanup)), and some code in unwind_to_catch, but of course that's a GCC extension and not something we can do outside the realm of debugging. Pip