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#58042: 29.0.50; ASAN use-after-free in re_match_2_internal Date: Wed, 05 Oct 2022 08:58:51 +0200 Message-ID: References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35961"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 58042@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 05 08:59:43 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 1ofyNZ-0009EL-Kf for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Oct 2022 08:59:41 +0200 Original-Received: from localhost ([::1]:51822 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ofyNY-0003uR-OP for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Oct 2022 02:59:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40734) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofyMy-0003sA-Fh for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2022 02:59:12 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56665) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ofyMw-0003lP-Gc for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2022 02:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ofyMv-0008L1-VO for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2022 02:59: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: Wed, 05 Oct 2022 06:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58042 X-GNU-PR-Package: emacs Original-Received: via spool by 58042-submit@debbugs.gnu.org id=B58042.166495314132043 (code B ref 58042); Wed, 05 Oct 2022 06:59:01 +0000 Original-Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 06:59:01 +0000 Original-Received: from localhost ([127.0.0.1]:55743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofyMu-0008Kl-SY for submit@debbugs.gnu.org; Wed, 05 Oct 2022 02:59:01 -0400 Original-Received: from mail-ej1-f46.google.com ([209.85.218.46]:36508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofyMt-0008KZ-OX for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 02:59:00 -0400 Original-Received: by mail-ej1-f46.google.com with SMTP id 13so33483479ejn.3 for <58042@debbugs.gnu.org>; Tue, 04 Oct 2022 23:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date; bh=q3K8F5AWdHcZtOq4zD18xl8D9Tz0u+ltwrAASFxoooE=; b=ZnmVZ6ssFYD9f8J4jpGw0l+VBMm47jaDyDqQi0Tx1BMOSUhup0BXTbS+bCS3+Ar6d9 Nk/LO5QRxygg+YBrcVHdsEljtc9WbGc4j/khBX1MmT/GG/xsXot/BVZDFI9LUTzREUGC vpGD5WvgpbdfUpG4beA3vQY6YtfGVkcohe5h0DDWLw4fik5YPrbS3HLhQPPXiL1hAyJs dOzBhB6Q1WgkRL/AniBofXtaLYet23ccdT9D8nd8Cce6rPJ16E7ZNoDuEyxVYX4p4nHA 1/Gn4GjNfdQR6Ackkj5E5jW8vakTVS0G11mWd+lVzkKwfiNnsFbq+ysS6x9FmSpbq0FF dy6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date; bh=q3K8F5AWdHcZtOq4zD18xl8D9Tz0u+ltwrAASFxoooE=; b=u3Tfuqi/9CpI80SaqWT+NtXtDneFAWdIixnbQwnfiaetD3NI47lYLVGC3g8eRpQKFs ny3jatx7PIKPtbDapUvXma7sN72GERwpcglFteogD9kBl1A68eZbgR+HLzBivw+6FNq5 pX8iSXic2ihGORtEjAC5Lqhbu6w2HjD+2sGqkMqsgge4J9IAcolHbMaHMHajVk3MBAa0 HlyLJvztcXfZ15bzB63ZsvYsau+2rE+FJrLw6gK7jzmy7Rjgp7KJLnv7iSXHV+/IfrqY tPm1ro8ubyvh4u8LqulTYRUYFAFw+zwvLLg/1RpSw77qcWmosdogjR7z2GY9dbtMG90t 7gZA== X-Gm-Message-State: ACrzQf0JsbHLZ+MEVbZ5B9rDh52nswLOt2Vm4xdUv1EIFuazfKxDU8q1 fijglO5KpwM3LWVf6iJrEnXS35Yj2DJnmw== X-Google-Smtp-Source: AMsMyM7YOKNvfmAt/5v2fZMuXSvMFxIzOveCXkaeiFMz1y/dD3urG2B0nxkoBIyhzM3ZzxpZCmKDGQ== X-Received: by 2002:a17:906:6a2a:b0:782:356e:4207 with SMTP id qw42-20020a1709066a2a00b00782356e4207mr22565212ejc.167.1664953133236; Tue, 04 Oct 2022 23:58:53 -0700 (PDT) Original-Received: from Mini.fritz.box (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id j18-20020a17090623f200b00783f32d7eaesm8190425ejg.164.2022.10.04.23.58.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Oct 2022 23:58:52 -0700 (PDT) In-Reply-To: <83pmf6u76i.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 05 Oct 2022 09:16:05 +0300") 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:244491 Archived-At: Eli Zaretskii writes: > Then I guess we will have to wait until LLDB folks get their act > together and fix LLDB to not crash before it provides the information > to us? Or is it possible for you to downgrade to the previous, > working version of LLDB? I'd rather not. If it's possible at all, I don't know, it's certainly a lot of work. BTW, I've submitted a bug report, as LLDB requested, because of the uppercase PLEASE :). Let's see if that lands anywhere. I don't have high hopes. > The question that we should try answering is this: what variable holds > the C pointer to the data of a Lisp string that is being relocated > and/or compacted by GC between the time the C pointer is assigned and > the time its value is dereferenced? I think we can answer that question, at least with a good probability. If you look what the offending (I think) pointer points to: frame #5: 0x0000000100582044 emacs`re_match_2_internal(bufp=0x000000010111ace8, string1=0x0000000000000000, size1=0, string2="/Users/gerd/.config/emacs.d.default/elpa/magit-section-20220901.331/puny.dylib", size2=78, pos=0, regs=0x0000000000000000, stop=78) at regex-emacs.c:4328:15 4325 DEBUG_PRINT ("EXECUTING anychar.\n"); 4326 4327 PREFETCH (); -> 4328 buf_ch = RE_STRING_CHAR_AND_LENGTH (d, buf_charlen, 4329 target_multibyte); 4330 buf_ch = TRANSLATE (buf_ch); 4331 if (buf_ch == '\n') (lldb) p d (re_char *) $285 = 0x000000011f90d0a1 "magit-section-20220901.331/puny.dylib" That looks like part of the filename here: frame #10: 0x0000000100503cf4 emacs`Ffind_file_name_handler(filename=(struct Lisp_String *) $318 = 0x000000011f6ec4c0, operation=(struct Lisp_Symbol *) $321 = 0x00000001010ec310) at fileio.c:324:24 321 operations = Fget (handler, Qoperations); 322 323 if (STRINGP (string) -> 324 && (match_pos = fast_string_match (string, filename)) > pos 325 && (NILP (operations) || ! NILP (Fmemq (operation, operations)))) 326 { 327 Lisp_Object tem; (lldb) p filename (Lisp_Object) $322 = 0x000000011f6ec4c4 (struct Lisp_String *) $324 = 0x000000011f6ec4c0 (lldb) p *$324 (struct Lisp_String) $325 = { u = { s = { size = 78 size_byte = -1 intervals = NULL data = 0x000000011f5d2f38 "/Users/gerd/.config/emacs.d.default/elpa/magit-section-20220901.331/puny.dylib" } next = 0x000000000000004e gcaligned = 'N' } } So, I'd say that the filename string data has been moved somewhere else during compaction. Which would mean GC somehow ran between the point where "d" in frame#5 was initially set up from the filename, and line 4328 where the problem is detected. > I don't see how to answer > that question without understanding how redisplay was called in the > middle of what seems to be loading of a Lisp package, because none of > the items 1 and 3 show anything that could call redisplay. What I can see is that, apparently, redisplay got called because Emacs received a MacOS event, and did a prepare_menu_bars etc etc. How that's possible, if it is, while Emacs is in between frame#10 and frame#5 I have not the slightest idea. And please note that this is all happening in the same thread T0, according to ASAN. Maybe someone knowing the Mac port has an idea if this can happen?