From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#56108: 29.0.50; ASAN use-after-free in re_match_2_internal Date: Thu, 23 Jun 2022 10:24:31 +0200 Message-ID: <84b39f74-b1dd-4485-b501-fc4a7e634455@Spark> References: <83mte7kv7c.fsf@gnu.org> <32e548cc-ffd3-4669-ad9a-317c130b0c93@Spark> <83a6a4kec0.fsf@gnu.org> <6e56407a-b564-4aa9-b74c-78883727ef09@Spark> <831qvgkc8d.fsf@gnu.org> <83sfnwisbb.fsf@gnu.org> <3146c990-63d9-4aa5-ab78-7bae2b7d6cd5@Spark> <835ykrg93i.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="62b42344_613183f2_588f" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1850"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56108@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 23 10:25:30 2022 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 1o4I9a-0000Lt-6g for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Jun 2022 10:25:30 +0200 Original-Received: from localhost ([::1]:49942 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4I9Z-0004xX-4n for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Jun 2022 04:25:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33092) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4I9B-0004ur-08 for bug-gnu-emacs@gnu.org; Thu, 23 Jun 2022 04:25:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43351) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o4I98-0003dx-1g for bug-gnu-emacs@gnu.org; Thu, 23 Jun 2022 04:25:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o4I97-0000hm-UL for bug-gnu-emacs@gnu.org; Thu, 23 Jun 2022 04:25:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Jun 2022 08:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56108 X-GNU-PR-Package: emacs Original-Received: via spool by 56108-submit@debbugs.gnu.org id=B56108.16559726872686 (code B ref 56108); Thu, 23 Jun 2022 08:25:01 +0000 Original-Received: (at 56108) by debbugs.gnu.org; 23 Jun 2022 08:24:47 +0000 Original-Received: from localhost ([127.0.0.1]:37248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o4I8s-0000hG-Mh for submit@debbugs.gnu.org; Thu, 23 Jun 2022 04:24:47 -0400 Original-Received: from mail-ed1-f46.google.com ([209.85.208.46]:43806) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o4I8q-0000h2-CW for 56108@debbugs.gnu.org; Thu, 23 Jun 2022 04:24:45 -0400 Original-Received: by mail-ed1-f46.google.com with SMTP id c13so22952160eds.10 for <56108@debbugs.gnu.org>; Thu, 23 Jun 2022 01:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=ahUrhk8pzLiEDk6HuYa9G29FtREXHpQFo0ItUlXCfBk=; b=a+KgWtXxyiXPdow4kOQey8v+nuR2CNJ9Yl0i25Gc2CZKU51hV2dZbYUg24AhP5ZKoD Jtz63kilXk75gu0btH5uSNbsGTAJ54Q4XL9fDVnLVwfFVSOAoSSSzcQLWnScRNSlbjY4 1cEKr8Gs9p0gC0VgywyfyLfDtPT0/YlHqak7+BC1myT1dyQwa2foXGW3s8phfmwOnm2h IiXdWEAKqoYUW9D1dTAwA8C/CTNL57fK5LComcB80sylDyMnztMpUhbbZOzaok3oVFCr usRxExgXaN/kFznzUOQ5EgVnDRbo5I//XaDWt63A8uya2yQtX5KSFRGA+j/7KMHs4ydc 4BXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=ahUrhk8pzLiEDk6HuYa9G29FtREXHpQFo0ItUlXCfBk=; b=Lz/ujQrTPL3QWkDwRvyX5BrF9WBOrjZgoH2MYGFUdhOLndB6cT/Wposaxj9ZmZWiN1 65pbiYORlVSropw0hOqZ9hBOztUOme4C4ZV8vmuTZsXeJ3jrfFy/98Aqx+UJyPglT8Aq MgpIz4t1iLqyXoyFZhyLrOgbmAiE2Z4Or+OmLAw3GBvXyHq6FnmEtWmiPKosNAs6kD3/ yjFdxDPbwlBlFQG7Eu8sIHfE+6ihCkuBQGcfgO3+a7zFONHi0ARkovnOeaOddg2EEdDA gul6Q5WhQP9ZRuzCP0Ctr4zziysGdnC9FwcfC0fs1OQdvwq2HFs+s8GV1PgsQXVu+1KS OESQ== X-Gm-Message-State: AJIora8mltS1W2RtF203NsKem/MZE8LfGrhTRBsakd7FbXoUwkE4kkKk pc9yVfk3B/lxFMhxnn5RgQ/kGFzzWFad17JA X-Google-Smtp-Source: AGRyM1ttIJLfhrs+nhnyAuKLlOwVCZE2PfoflOwmrx6KnBPGWqKBW/p/8ybaLEb9qT59xUALxRzw8Q== X-Received: by 2002:a05:6402:1d48:b0:42d:d1a2:7c6d with SMTP id dz8-20020a0564021d4800b0042dd1a27c6dmr9136966edb.43.1655972678664; Thu, 23 Jun 2022 01:24:38 -0700 (PDT) Original-Received: from [192.168.178.21] (pd9e367fb.dip0.t-ipconnect.de. [217.227.103.251]) by smtp.gmail.com with ESMTPSA id o2-20020a170906768200b0070b8a467c82sm10361440ejm.22.2022.06.23.01.24.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jun 2022 01:24:37 -0700 (PDT) In-Reply-To: <835ykrg93i.fsf@gnu.org> X-Readdle-Message-ID: 84b39f74-b1dd-4485-b501-fc4a7e634455@Spark 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:235080 Archived-At: --62b42344_613183f2_588f Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 23. Jun 2022, 08:58 +0200, Eli Zaretskii , wrote: > > Do you want to do that or should I=3F > > > > =46eel free to do it, I generally prefer that people who see the prob= lem > > and could at least potentially test the solution also make the change= > > to fix it. > > Ok > > > > Another side question, if I may: Have you perhaps heard of someone pr= oducing a static call graph for > > Emacs, or better yet, specific functions in Emacs=3F Maybe using objd= ump -D or something similar=3F > > > > Does this make sense in a dynamic program such as Emacs=3F We call in= to > > Lisp quite a lot from C, and from there you can arrive anywhere, no=3F= > > And objdump cannot capture Lisp levels. True, but for GC at least, I think it would make it easier to tell if it = can potentially happen. One would see a call to GC in the static call gra= ph. Not for arbitrary lines, of course, you know what I mean... > > > > That is, btw, the main problem with maintaining Emacs internals > > nowadays: it is hard, almost impossible, to know, just by looking at = C > > code, whether GC or any other Lisp-related activity could happen > > between two arbitrary lines of C. We have more and more hooks called > > from C that could potentially call any Lisp, and we have more and mor= e > > direct calls into Lisp from the most intimate parts of Emacs, like th= e > > display engine and the main loop in keyboard.c. This basically makes > > any analysis of whether or not some code fragment could cause GC > > futile: even if today it's impossible, it can easily become possible > > tomorrow, with some innocent-looking change. This is exacerbated by > > the fact that GCPROs are long gone, so the caution we used to > > exercised 20 years ago to make sure GC doesn't surprise us is no > > longer needed nor practiced. > > All true, I just want to remark that I have no fond memories of GCPRO, an= d of debugging stuff caused by missing ones.=C2=A0 =C2=A0Glad to hear the= y're finally completely dead now. > > > > But no, I don't think anyone tried to see what kind of graph could be= > > obtained. Maybe it's worthwhile, who knows=3F we might learn somethin= g > > useful regardless. Thanks --62b42344_613183f2_588f Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On 23. Jun 2022, 08:58 +0200, Eli Zaretskii <eli= z=40gnu.org>, wrote:
Do you want to do that or should I=3F

=46eel free to do it, I generally prefer that people who see the problem<= br /> and could at least potentially test the solution also make the change
to fix it.

Ok

Another side question, if I may: Have you perhaps heard of someone produc= ing a static call graph for
Emacs, or better yet, specific functions in Emacs=3F Maybe using objdump = -D or something similar=3F

Does this make sense in a dynamic program such as Emacs=3F We call into Lisp quite a lot from C, and from there you can arrive anywhere, no=3F And objdump cannot capture Lisp levels.
True, but for GC at least, I think it would make it= easier to tell if it can potentially happen. One would see a call to GC = in the static call graph. Not for arbitrary lines, of course, you know wh= at I mean...

That is, btw, the main problem with maintaining Emacs internals
nowadays: it is hard, almost impossible, to know, just by looking at C code, whether GC or any other Lisp-related activity could happen
between two arbitrary lines of C. We have more and more hooks called
from C that could potentially call any Lisp, and we have more and more direct calls into Lisp from the most intimate parts of Emacs, like the display engine and the main loop in keyboard.c. This basically makes
any analysis of whether or not some code fragment could cause GC
futile: even if today it's impossible, it can easily become possible
tomorrow, with some innocent-looking change. This is exacerbated by
= the fact that GCPROs are long gone, so the caution we used to
exercised 20 years ago to make sure GC doesn't surprise us is no
longer needed nor practiced.

All true, I just want to remark that I have no fond= memories of GCPRO, and of debugging stuff caused by missing ones.&=23160= ; &=23160;Glad to hear they're finally completely dead now.

But no, I don't think anyone tried to see what kind of graph could be
obtained. Maybe it's worthwhile, who knows=3F we might learn something useful regardless.
Thanks
--62b42344_613183f2_588f--