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.devel Subject: Re: master d582356: * src/fns.c (Frandom): Handle bignum `limit`s Date: Sun, 7 Mar 2021 19:55:19 +0000 Message-ID: References: <20210305170955.27732.27579@vcs0.savannah.gnu.org> <20210305170957.AF99920E1B@vcs0.savannah.gnu.org> <83sg58wu0v.fsf@gnu.org> <83k0qkwnwt.fsf@gnu.org> <838s70wdb5.fsf@gnu.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="23332"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 07 20:56:49 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lIzWC-0005y1-JZ for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Mar 2021 20:56:48 +0100 Original-Received: from localhost ([::1]:33682 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIzWB-00050t-Lg for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Mar 2021 14:56:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53068) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lIzVP-0004MP-W7 for emacs-devel@gnu.org; Sun, 07 Mar 2021 14:56:00 -0500 Original-Received: from mail-oo1-xc30.google.com ([2607:f8b0:4864:20::c30]:33555) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lIzVO-0006sE-43; Sun, 07 Mar 2021 14:55:59 -0500 Original-Received: by mail-oo1-xc30.google.com with SMTP id z22so1729270oop.0; Sun, 07 Mar 2021 11:55:56 -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=Snwc0hsghUNaOwEbmPhj9TbxCC8DyUh0v/ixRdTTmYM=; b=VxQm3mWusRz/5j0lI6od6XSK8/2Lt9mofpcy4ZrSlxsNOSs3n7Fu3MhG6qipLJ/1dq vTSPEuoiYCjsihIF9BLiCcWGd0/v+9gt1Dh39KmBZyqIWuNUL6ASRP4LODO/3luLxkRk xII1Jmfu7Dn5q2/qLyChbe6O+zi2dAW2rWig3hlgCdm9WNcBnFjB3e9CN7FpNpQnebJh y7C82z6IamIokcmwsdXLKErWEtdKzq1wELCIJ4T6Ci6/ccy/6rHETeFzlq97XRFUC91r HgQCwNa3BWP+Qma6/buwCPjMzHP+Ge061c+JQAuEoG85CMdeyn25vJyXu2KFqW5PhDuR cQTg== 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=Snwc0hsghUNaOwEbmPhj9TbxCC8DyUh0v/ixRdTTmYM=; b=cZ9Tssgv9mNIILIEans9jqs8afqrkBF7CqIRzE3IxfQUhRxSSMQjQ8NtPYV2kDizrL icHx1QuCN5d9zGpak2C5NI9/nT7lnsYKpz3m3Mn9D82/obargrS/nmcaOVGA5lamHGJ/ W+JyCm360ubbSOLID1cbDXf0WIhk3+R7xlcPpihkmJuZyuNyUJXcVb47hkAPC1TbSKbP HuN5M2Tsvn8BXDVRutSdvVUwL9+Al/95NUGIgj2MxXSAvYsA5XApMace9Gw+BzYwNUdv tXksNQtr+jhldOjlz2vnfVrR+zdSXP7/iLXlf19yCFJmgmulO+s8owg1dsKCBflJj+BU vMog== X-Gm-Message-State: AOAM530gh9OCki8vE1Q4TZBAxvx2X3WXICijdCX4TJtm+b044AB95CCW v0ZSAkyi3pD1w05AXHql1MOxMXgfkNCA9TQ48Pc= X-Google-Smtp-Source: ABdhPJxcctRR87lEdFL0iWoqsIvm+/zc/ZTqWolIzNfpAMJFHtOzzjVr62Tixkb+sgjYYKc3WpWb5zHoSyHTJ0no8zs= X-Received: by 2002:a4a:d781:: with SMTP id c1mr16170223oou.44.1615146955997; Sun, 07 Mar 2021 11:55:55 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::c30; envelope-from=pipcet@gmail.com; helo=mail-oo1-xc30.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:266148 Archived-At: On Sun, Mar 7, 2021 at 6:37 PM Stefan Monnier wrote: > >> I don't think I understand how will we know which function says it > >> never calls GC. > > By tagging it in the source code? > > Random thoughts on this: > - AFAIK in the current code, the places where we can't run GC are much > more rare than the cases where we can run GC, so we'd be better off > trying to annotate the places where it can't happen. I think there's one exception: DEFUNs should be assumed to call GC unless they're explicitly tagged as not doing so, and they should assert they're allowed to call GC when run (again, unless explicitly tagged as not requiring GC). > - Those places are currently not annotated at all, by and large. > There are a few comments here and there stating that GC shouldn't > happen, but those comments shouldn't be trusted. Indeed. > - The trend is to reduce the amount of code where GC cannot take place > [ I think and I hope. ] There are several analogous problems, IMHO: 1. Code that can't GC 2. Code that can't quit 3. Code that leaves my X session in an unusable state if gdb interrupts it 4. Code that mustn't call Lisp (signal handlers) 5. Code that mustn't call malloc 6. Code that never signals an error I think (5) is less of an issue now that reentrant libcs are a thing, and I'll freely admit I don't understand (3) (or the X/Wayland situation, at all). But my suspicion is critical sections of one kind or another will keep coming up. > - As you have noted some functions can be called in contexts where they > may GC and in other contexts where they may not GC. So we don't have > a clear static partitioning of the code. So maybe a dynamic-test > approach is the better option (it will rarely catch the unlikely > corner cases, but if it does catch them in their rare occurrences it'll > still help us diagnose those problems which tend to be very painful > to track down). I'm currently leaning towards a dynamic approach together with running GCC with -fanalyzer -flto. (IIUC, the analyzer differs from normal warning passes in that it tries a hell of a lot harder to prove the code is okay, but if it fails to do so, it outputs a warning rather than erring on the side of caution. For example, verify_interval_modification in textprop.c generates a warning; i and prev are two variables which cannot simultaneously both be NULL (but either one of them can be), and code dereferences them in the i == prev branch of an if. The code's correct, but it's definitely not obviously correct.) So I hope the analyzer will be able to turn the dynamic check into a static check given a few starting points... And as I said, I think DEFUNs are a good starting point, because it's easy to redefine DEFUN() to define a wrapper around the actual Fwhatever function instead of the Fwhatever function directly. But what I would like to know is whether it's potentially worth it to investigate this further. If there's a strong consensus (or a maintainer veto implying) that we'd rather keep catching bugs by hand, well, I'd rather know. I'd also like to point out that this approach is not cheap. Running the analyzer on an LTO'd Emacs (compiled with -O0; I don't know whether that makes it slower or faster) takes 20 GB of RAM and 5 minutes of CPU time, and that's with the configurable parameters tuned down quite a bit. Pip