From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 24 09:45:54 2022 Received: (at submit) by debbugs.gnu.org; 24 Sep 2022 13:45:54 +0000 Received: from localhost ([127.0.0.1]:42780 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oc5Te-0000Zk-H1 for submit@debbugs.gnu.org; Sat, 24 Sep 2022 09:45:54 -0400 Received: from lists.gnu.org ([209.51.188.17]:37682) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oc5Tb-0000Za-O0 for submit@debbugs.gnu.org; Sat, 24 Sep 2022 09:45:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44662) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oc5TW-0007k4-72 for bug-gnu-emacs@gnu.org; Sat, 24 Sep 2022 09:45:48 -0400 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]:33394) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oc5TU-0004KE-C4 for bug-gnu-emacs@gnu.org; Sat, 24 Sep 2022 09:45:45 -0400 Received: by mail-ej1-x635.google.com with SMTP id lc7so5928764ejb.0 for ; Sat, 24 Sep 2022 06:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date; bh=LpScj4Ou50wnyQHrbftskh9HUrwV8Qg6iGdRyYw4T+8=; b=PuAwx+SndxPIA79dBrPz+Rttp7TIBmtbNJhbzTnwUwDxAYlf/eJeFfB7tKkaUmyrvF 8vCu2i4FFYbG+bieAu/SNOwM/CxP7f0nyRRlSJg3iocX0ciwNOOgpWGK1X3BBeAmIwTt RfollNUrl4ZAT7nq9aC+RNdX+CuLKnpLZxr9vzeAEx9zLla016DXOEs5uSjuFP6cv+AG nK76j3aJXVD8aYTT919EChC4g8UcKmEYcT6s/6zP9mO9pdvVxd249K/eTT2JySJkpy80 W84yv2omvrC5btfNove/KFtdrBRFBzep+TgK/nGnD4vrMjYA5uhkmtaeYjIAY1Wnv0Uj mWcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date; bh=LpScj4Ou50wnyQHrbftskh9HUrwV8Qg6iGdRyYw4T+8=; b=SoyMD9scGIu4ejyrS7IJUx4uiGHC+fBOvVpsYDGSAwvGbqtO/jbLxnR4iSnnu9k24H 1Dvv34JGxSsTaDgNnM2txHXunk4lxGCNEZJFCyUmx9DOK7ouPzakAvGQhvvGLWzOTDJX bX2RLG1cgyNziuZmkmMQE7FqTUr7BBCtP/v6m3VBOHXpPPTUIs185PW636Dhw2rh17Yp b9C5Z536yrM27FzV7CGhKPQxmUZw0wM9ntr6b9Myh8oSJMdVbm8BjV5NazKvczVNnxWr eLbt8QF+p9QibTHvGzmRgWCY9m+0wjHRnW7gaIPcx2AZ159Uu2OySvAz3Qopy+vmrocR EO5Q== X-Gm-Message-State: ACrzQf3eiNawp7qqFRDM8/SOoRgI6WTmgOTk9mwgUeqITONfDbChrWRc 0ZggZbCIUBxw+bwwgQWVVW7V3wP5ohg= X-Google-Smtp-Source: AMsMyM4JhTYTyxOQdP1eelvyPHDoiRcvV0GSmZE/lk4gHXn2IdQWciOEwG+xQByhh+Q9oE0/tlsDcw== X-Received: by 2002:a17:907:2d9e:b0:782:69f2:a0ec with SMTP id gt30-20020a1709072d9e00b0078269f2a0ecmr9567049ejc.680.1664027141829; Sat, 24 Sep 2022 06:45:41 -0700 (PDT) Received: from Mini.fritz.box (p4fe3a935.dip0.t-ipconnect.de. [79.227.169.53]) by smtp.gmail.com with ESMTPSA id f2-20020a17090631c200b007826c0a05ecsm3252189ejf.209.2022.09.24.06.45.40 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Sep 2022 06:45:41 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: bug-gnu-emacs@gnu.org Subject: 29.0.50; ASAN use-after-free in re_match_2_internal Date: Sat, 24 Sep 2022 15:45:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::635; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x635.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-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) In GNU Emacs 29.0.50 (build 1, aarch64-apple-darwin21.6.0, NS appkit-2113.60 Version 12.6 (Build 21G115)) of 2022-09-21 built on Mini.fritz.box Repository revision: 1231a601ebe1fd9fe454c504dbeb9267440242e7 Repository branch: master Windowing system distributor 'Apple', version 10.3.2113 System Description: macOS 12.6 Configured using: 'configure --cache-file /Users/gerd/tmp/config.cache.master --with-native-compilation' Configured features: ACL DBUS GLIB GNUTLS JSON LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS XIM ZLIB I got the following ASAN error today. Unfortunately, I don't have the slightest idea how to reproduce this. ==79227==ERROR: AddressSanitizer: heap-use-after-free on address 0x00011f81e7d1 at pc 0x0001005825c4 bp 0x00016fdcf370 sp 0x00016fdcf368 READ of size 1 at 0x00011f81e7d1 thread T0 #0 0x1005825c0 in re_match_2_internal regex-emacs.c:4352 #1 0x10057e5cc in rpl_re_search_2 regex-emacs.c:3383 #2 0x10057d1c4 in rpl_re_search regex-emacs.c:3177 #3 0x10056115c in fast_string_match_internal search.c:492 #4 0x1005045c0 in fast_string_match lisp.h:4818 #5 0x100504018 in Ffind_file_name_handler fileio.c:324 #6 0x1006dbe5c in openp lread.c:1911 #7 0x1006d8844 in Fload lread.c:1302 #8 0x1006e1af0 in save_match_data_load lread.c:1630 #9 0x10064f8cc in load_with_autoload_queue eval.c:2269 #10 0x10067d2f8 in Frequire fns.c:3274 previously allocated by thread T0 here: #0 0x103332ca8 in wrap_malloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3eca8) #1 0x1005ae8fc in lmalloc alloc.c:1361 #2 0x1005b0188 in lisp_malloc alloc.c:994 #3 0x1005b0a5c in allocate_string_data alloc.c:1889 #4 0x1005b1bd8 in make_clear_multibyte_string alloc.c:2475 #5 0x1005b1670 in make_clear_string alloc.c:2443 #6 0x1005b2714 in make_uninit_string alloc.c:2454 #7 0x100666c14 in concat_to_string fns.c:821 #8 0x100666420 in concat2 fns.c:600 #9 0x1006d7870 in Fget_load_suffixes lread.c:1123 #10 0x1006d86ac in Fload lread.c:1296 #11 0x1006e1af0 in save_match_data_load lread.c:1630 #12 0x10064f8cc in load_with_autoload_queue eval.c:2269 rame #5: 0x00000001005825c4 emacs`re_match_2_internal(bufp=0x000000010111b890, string1=0x0000000000000000, size1=0, string2="/Users/gerd/.config/emacs.d.default/elpa/company-0.9.13/lsp-protocol.el.gz", size2=74, pos=0, regs=0x0000000000000000, stop=74) at regex-emacs.c:4352:18 4349 4350 PREFETCH (); 4351 int len; -> 4352 int corig = RE_STRING_CHAR_AND_LENGTH (d, len, target_multibyte); 4353 int c = corig; 4354 if (target_multibyte) 4355 { And to make things worse, I can't get an xbacktrace because the "new" lldb, which I got with Xcode 14, says it has a bug. Tadah :-/. (lldb) xbacktrace PLEASE submit a bug report to https://developer.apple.com/bug-reporting/ and include the crash backtrace. Stack dump: From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 24 10:17:33 2022 Received: (at 58042) by debbugs.gnu.org; 24 Sep 2022 14:17:33 +0000 Received: from localhost ([127.0.0.1]:44890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oc5yH-0001uh-1Z for submit@debbugs.gnu.org; Sat, 24 Sep 2022 10:17:33 -0400 Received: from mail-ej1-f54.google.com ([209.85.218.54]:44720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oc5yE-0001uR-CW for 58042@debbugs.gnu.org; Sat, 24 Sep 2022 10:17:31 -0400 Received: by mail-ej1-f54.google.com with SMTP id r18so5853632eja.11 for <58042@debbugs.gnu.org>; Sat, 24 Sep 2022 07:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:to:from:from:to:cc:subject:date; bh=5e9vkGhvPM87qr443hzo5wyokUWlpX6uKcRzvBDSsU4=; b=btzmFZGNq9GVZfdXXi5aR0sPytf4G7E4myAo8wgo6Sdw2O0A6lIL/ilA2QqQKVgv6u /vC3f8/GBTyr0zzqzZBnX/Os89JZQ98iZG3GYshZB2XH1esU7DvTLxyndX3A4SWy6ps5 I3taL6SAugJiu2LsJIwhCUB2T+aqswwz5HjEK4vaxPgQA991wG/A36KME4rl7xzXxFvB jQxhSwuen4U4aNELbYCiKOtWXqMUEJxcc6K+o7ltM3G82jJUYqwx6czRGYMkBqCsY8BL R6spkrCRzEGPIT/FP+AFngSzKvCWe3x22wSf9bvWMd3aUUQUMLNrmWsiYpzHLfsnGn6a S8kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:to:from:x-gm-message-state:from:to :cc:subject:date; bh=5e9vkGhvPM87qr443hzo5wyokUWlpX6uKcRzvBDSsU4=; b=A2ze8rDfze44AvHsb86TA05IVFkemIDfbOckhe6WD0M+Ns7PB0vlct0RK+RwKcQ3kq XnMCLsY1r2x52TpnWUJZRNPtslHXaL1XFPi8maqjE9bIh4j5Iqo6b40hInt6Ei8I4Hzi 5KnhjLEJXeBr19lh7dlrpE56DE125xcizGey+5p/nOw/gMnbqAXelTEeItpfiFEkZYvN Mpsxdgza1noMPBKFQvRWu5LM8DG8iECH3tifhbXGDM6IYhi059P+mMg3s9jt0D+FMKHs CGO1PR5IdHuUNE82zoiPwNVFUC0ahkHtQMpgGzf15J6BdWGBrfv2k/dOOS4QynIpwSs9 rOcA== X-Gm-Message-State: ACrzQf2f+c/VDmpIaU2mGe1gfgkPV99hOV/5hoNtMmG7D4LRvQMrYoxu goPHpHkSoU4uERp++o/aOvwIt4cQ328= X-Google-Smtp-Source: AMsMyM7NPwDCbMAz/BxZtJGD2POt3ajAdt327A58RDVf4vRP5y9Hl7Kk6nKFsSD9iJVGejSMeQkCpA== X-Received: by 2002:a17:906:7945:b0:73b:e605:f31 with SMTP id l5-20020a170906794500b0073be6050f31mr11125939ejo.129.1664029042768; Sat, 24 Sep 2022 07:17:22 -0700 (PDT) Received: from Mini.fritz.box (p4fe3a935.dip0.t-ipconnect.de. [79.227.169.53]) by smtp.gmail.com with ESMTPSA id kz15-20020a17090777cf00b0073c82539183sm5457366ejc.91.2022.09.24.07.17.21 for <58042@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Sep 2022 07:17:21 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: 58042@debbugs.gnu.org Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Sat, 24 Sep 2022 15:45:39 +0200") References: Date: Sat, 24 Sep 2022 16:17:20 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > In GNU Emacs 29.0.50 (build 1, aarch64-apple-darwin21.6.0, NS > appkit-2113.60 Version 12.6 (Build 21G115)) of 2022-09-21 built on > Mini.fritz.box > Repository revision: 1231a601ebe1fd9fe454c504dbeb9267440242e7 > Repository branch: master > Windowing system distributor 'Apple', version 10.3.2113 > System Description: macOS 12.6 > > Configured using: > 'configure --cache-file /Users/gerd/tmp/config.cache.master > --with-native-compilation' >=20=20 > Configured features: > ACL DBUS GLIB GNUTLS JSON LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY > KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS XIM ZLIB > > I got the following ASAN error today. Unfortunately, I don't have the > slightest idea how to reproduce this. > > =3D=3D79227=3D=3DERROR: AddressSanitizer: heap-use-after-free on address = 0x00011f81e7d1 at pc 0x0001005825c4 bp 0x00016fdcf370 sp 0x00016fdcf368 > READ of size 1 at 0x00011f81e7d1 thread T0 > #0 0x1005825c0 in re_match_2_internal regex-emacs.c:4352 > #1 0x10057e5cc in rpl_re_search_2 regex-emacs.c:3383 > #2 0x10057d1c4 in rpl_re_search regex-emacs.c:3177 > #3 0x10056115c in fast_string_match_internal search.c:492 > #4 0x1005045c0 in fast_string_match lisp.h:4818 > #5 0x100504018 in Ffind_file_name_handler fileio.c:324 > #6 0x1006dbe5c in openp lread.c:1911 > #7 0x1006d8844 in Fload lread.c:1302 > #8 0x1006e1af0 in save_match_data_load lread.c:1630 > #9 0x10064f8cc in load_with_autoload_queue eval.c:2269 > #10 0x10067d2f8 in Frequire fns.c:3274 Forget to copy the part where it is freed: freed by thread T0 here: #0 0x103332de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:ar= m64e+0x3ede4) #1 0x100985e38 in rpl_free free.c:48 #2 0x1005b71a4 in lisp_free alloc.c:1038 #3 0x1005cbda4 in compact_small_strings alloc.c:2191 #4 0x1005c9f24 in sweep_strings alloc.c:2072 #5 0x1005bd028 in gc_sweep alloc.c:7397 #6 0x1005bb178 in garbage_collect alloc.c:6245 #7 0x1005ba694 in maybe_garbage_collect alloc.c:6090 #8 0x1006505ac in maybe_gc lisp.h:5624 #9 0x100648ffc in Ffuncall eval.c:2972 #10 0x10064bcd0 in internal_condition_case_n eval.c:1555 #11 0x1000cdc8c in safe__call xdisp.c:3026 #12 0x1000cdfc4 in safe__call1 xdisp.c:3062 #13 0x1001d6404 in prepare_menu_bars xdisp.c:13572 #14 0x1000f2340 in redisplay_internal xdisp.c:16523 #15 0x100108f34 in redisplay xdisp.c:16105 #16 0x10088fa84 in -[EmacsView layoutSublayersOfLayer:] nsterm.m:8662 #17 0x1900a9624 in CA::Layer::layout_if_needed(CA::Transaction*)+0x224 = (QuartzCore:arm64e+0x20624) #18 0x1901f661c in CA::Context::commit_transaction(CA::Transaction*, do= uble, double*)+0x1c0 (QuartzCore:arm64e+0x16d61c) #19 0x19008b4c8 in CA::Transaction::commit()+0x2bc (QuartzCore:arm64e+0= x24c8) #20 0x18bee1698 in __62+[CATransaction(NSCATransaction) NS_setFlushesWi= thDisplayLink]_block_invoke+0x12c (AppKit:arm64e+0x1ac698) #21 0x18c646754 in ___NSRunLoopObserverCreateWithHandler_block_invoke+0= x3c (AppKit:arm64e+0x911754) #22 0x1892101a0 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_F= UNCTION__+0x20 (CoreFoundation:arm64e+0x841a0) #23 0x18920fff0 in __CFRunLoopDoObservers+0x24c (CoreFoundation:arm64e+= 0x83ff0) #24 0x18920f524 in __CFRunLoopRun+0x300 (CoreFoundation:arm64e+0x83524) #25 0x18920ea80 in CFRunLoopRunSpecific+0x254 (CoreFoundation:arm64e+0x= 82a80) #26 0x191e4e334 in RunCurrentEventLoopInMode+0x120 (HIToolbox:arm64e+0x= 32334) #27 0x191e4dfc0 in ReceiveNextEventCommon+0x140 (HIToolbox:arm64e+0x31f= c0) #28 0x191e4de64 in _BlockUntilNextEventMatchingListInModeWithFilter+0x4= 4 (HIToolbox:arm64e+0x31e64) #29 0x18bd76518 in _DPSNextEvent+0x358 (AppKit:arm64e+0x41518) > > previously allocated by thread T0 here: > #0 0x103332ca8 in wrap_malloc+0x94 (libclang_rt.asan_osx_dynamic.dyli= b:arm64e+0x3eca8) > #1 0x1005ae8fc in lmalloc alloc.c:1361 > #2 0x1005b0188 in lisp_malloc alloc.c:994 > #3 0x1005b0a5c in allocate_string_data alloc.c:1889 > #4 0x1005b1bd8 in make_clear_multibyte_string alloc.c:2475 > #5 0x1005b1670 in make_clear_string alloc.c:2443 > #6 0x1005b2714 in make_uninit_string alloc.c:2454 > #7 0x100666c14 in concat_to_string fns.c:821 > #8 0x100666420 in concat2 fns.c:600 > #9 0x1006d7870 in Fget_load_suffixes lread.c:1123 > #10 0x1006d86ac in Fload lread.c:1296 > #11 0x1006e1af0 in save_match_data_load lread.c:1630 > #12 0x10064f8cc in load_with_autoload_queue eval.c:2269 > > rame #5: 0x00000001005825c4 emacs`re_match_2_internal(bufp=3D0x0000000101= 11b890, string1=3D0x0000000000000000, size1=3D0, string2=3D"/Users/gerd/.co= nfig/emacs.d.default/elpa/company-0.9.13/lsp-protocol.el.gz", size2=3D74, p= os=3D0, regs=3D0x0000000000000000, stop=3D74) at regex-emacs.c:4352:18 > 4349=09 > 4350 PREFETCH (); > 4351 int len; > -> 4352 int corig =3D RE_STRING_CHAR_AND_LENGTH (d, len, target_mult= ibyte); > 4353 int c =3D corig; > 4354 if (target_multibyte) > 4355 { > > And to make things worse, I can't get an xbacktrace because the "new" > lldb, which I got with Xcode 14, says it has a bug. Tadah :-/. > > (lldb) xbacktrace > PLEASE submit a bug report to https://developer.apple.com/bug-reporting/ = and include the crash backtrace. > Stack dump: From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 24 10:48:39 2022 Received: (at 58042) by debbugs.gnu.org; 24 Sep 2022 14:48:39 +0000 Received: from localhost ([127.0.0.1]:44904 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oc6SN-0002gO-C7 for submit@debbugs.gnu.org; Sat, 24 Sep 2022 10:48:39 -0400 Received: from mail-ej1-f51.google.com ([209.85.218.51]:36475) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oc6SL-0002gB-Dq for 58042@debbugs.gnu.org; Sat, 24 Sep 2022 10:48:38 -0400 Received: by mail-ej1-f51.google.com with SMTP id 13so6026366ejn.3 for <58042@debbugs.gnu.org>; Sat, 24 Sep 2022 07:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:to:from:from:to:cc:subject:date; bh=egNrnR7eQbAjzz48ywLbnouVjQKjp3Kc106VVMOcweM=; b=JsDgGYb7fCEeJvK7zRFVfdjRA2FniKwycMl/qQtgdNV/CxkF1Z6bG259vhuYuEjSxY 19g1a8Iv3VzOZr8bn9N9C6HC1kds3Y2X8kOOidSfTvPQDjHID9eDbLzXAt0ZaMu3Vta2 8d4KE8FJ3WArfO2/OSXzIWC8BCHmhZ8JHgDm9dTwzOamYVvSwitApTZYO5igprhkffvj T+rBm/CI9Tkf6Ct+/kQ0/P8GhGLP3F+s89MxL5Kxb1h5Fh+qg8Ve+5gLYlDIWElFIzTA hO2H3/LvWauZwCdaye4VZooRoH3eiUW71KRq1xWFMcJa0iEa7n6Qo2Ljw0uEkIh3RK6r ZV3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:to:from:x-gm-message-state:from:to :cc:subject:date; bh=egNrnR7eQbAjzz48ywLbnouVjQKjp3Kc106VVMOcweM=; b=LPrda3M5/GeETh2vZZZGtYUNjjDUPllDIcKvh68Tcxmiuc4eSSDXPybL49PohxalD+ hQXQP9ZE3uO/YHX23ruBFOLt0R+h49RXEblxwW5VwWzm/uDE87vJVYeBqFx8Gx7xyoKT +zdsvhrT5cDvbKxxCjlM7wTFtUxhQxG7XuxGpSWcJ/Nx2nXdYqNede3VGzvMWwiNGR6t 6KF6kaBdAMhub2FaZE4CZ7QCgo8XuQijsKvyseBdCzrCOzHJyJRXiQIRho5ASV2HHPSN dC9Xz8c4W84kig2mqr7ur0tbOeRAjZ5y7EmaWvjBw5F1O9WGZJ7eXGpXBzHoaThq1KJV +6jg== X-Gm-Message-State: ACrzQf3TF+1fU7NWNX86/g3n3ErVMtYvlk3x/M5ZGgjCtZAcEIVECfVX H0aC+SHkcJ+q4Mav4vBT+a6ZPCEEAC8= X-Google-Smtp-Source: AMsMyM7Rcf48wk6Y8olGDL6HRhZ7YdRomj1ITfzHj/VRtNmel0qH4LK6ZPIrXsOMNYFi0hLpeD456A== X-Received: by 2002:a17:907:da9:b0:780:5fe8:f8d7 with SMTP id go41-20020a1709070da900b007805fe8f8d7mr11418280ejc.357.1664030911112; Sat, 24 Sep 2022 07:48:31 -0700 (PDT) Received: from Mini.fritz.box (p4fe3a935.dip0.t-ipconnect.de. [79.227.169.53]) by smtp.gmail.com with ESMTPSA id cz9-20020a0564021ca900b00447e5983478sm3192982edb.76.2022.09.24.07.48.30 for <58042@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Sep 2022 07:48:30 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: 58042@debbugs.gnu.org Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Sat, 24 Sep 2022 16:17:20 +0200") References: Date: Sat, 24 Sep 2022 16:48:29 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Gerd M=C3=B6llmann writes: >> =3D=3D79227=3D=3DERROR: AddressSanitizer: heap-use-after-free on address= 0x00011f81e7d1 at pc 0x0001005825c4 bp 0x00016fdcf370 sp 0x00016fdcf368 >> READ of size 1 at 0x00011f81e7d1 thread T0 >> #0 0x1005825c0 in re_match_2_internal regex-emacs.c:4352 >> #1 0x10057e5cc in rpl_re_search_2 regex-emacs.c:3383 >> #2 0x10057d1c4 in rpl_re_search regex-emacs.c:3177 >> #3 0x10056115c in fast_string_match_internal search.c:492 >> #4 0x1005045c0 in fast_string_match lisp.h:4818 >> #5 0x100504018 in Ffind_file_name_handler fileio.c:324 >> #6 0x1006dbe5c in openp lread.c:1911 >> #7 0x1006d8844 in Fload lread.c:1302 >> #8 0x1006e1af0 in save_match_data_load lread.c:1630 >> #9 0x10064f8cc in load_with_autoload_queue eval.c:2269 >> #10 0x10067d2f8 in Frequire fns.c:3274 Here's a guess: Suppose that strings a compacted in a GC happening between fast_string_match and re_match_2_internal. That GC compacts strings, moves the data of the string being matched from one block to another, and the block where the string data used to be is freed. Then the char* used in the regexp machine point into no-man's-land. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 24 10:57:17 2022 Received: (at 58042) by debbugs.gnu.org; 24 Sep 2022 14:57:17 +0000 Received: from localhost ([127.0.0.1]:44909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oc6aj-0002sc-Dm for submit@debbugs.gnu.org; Sat, 24 Sep 2022 10:57:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35102) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oc6ah-0002sO-EV for 58042@debbugs.gnu.org; Sat, 24 Sep 2022 10:57:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35404) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oc6ac-000650-4b; Sat, 24 Sep 2022 10:57:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=lNKN33By/qXYSFpNdQZSnnmTgnGN9sq3bPaJ+8MXY7I=; b=Dj3Ba9i8kSp8D01MXJ48 P6lZMIsGsDl1a6ByyQo7pwA7zgQzR2sFsOTwWiT99nkmKPe3VLtop5X7zAPeYTBA1ldc6+2zX4OxB ppM/3rellryEKJ3sdYqRk7hhxdxTfq7FxMfdDFfSN/ZIdC4zsjlx0DAdl78mvEjmCxGQh9Pl4iJS5 geNgcAPYRBYTgOR4oqJXDfYvLHh3UCX116Su8wIJZF2SNIChy2utEWEm/gMuvM2/TSVBskUscJ/d8 x3dYlgv1gKzmDA5cPXSfALanIOEd5YxIwEAvrUav/cqFLAafG9lG7MdrxYVtCGegTMz+vPBXoOb0O B/1SNhZZOHJvmQ==; Received: from [87.69.77.57] (port=3166 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oc6ab-000651-KS; Sat, 24 Sep 2022 10:57:09 -0400 Date: Sat, 24 Sep 2022 17:56:55 +0300 Message-Id: <835yhcom6g.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Sat, 24 Sep 2022 16:17:20 +0200) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Date: Sat, 24 Sep 2022 16:17:20 +0200 > > Gerd Möllmann writes: > > > ==79227==ERROR: AddressSanitizer: heap-use-after-free on address 0x00011f81e7d1 at pc 0x0001005825c4 bp 0x00016fdcf370 sp 0x00016fdcf368 > > READ of size 1 at 0x00011f81e7d1 thread T0 > > #0 0x1005825c0 in re_match_2_internal regex-emacs.c:4352 > > #1 0x10057e5cc in rpl_re_search_2 regex-emacs.c:3383 > > #2 0x10057d1c4 in rpl_re_search regex-emacs.c:3177 > > #3 0x10056115c in fast_string_match_internal search.c:492 > > #4 0x1005045c0 in fast_string_match lisp.h:4818 > > #5 0x100504018 in Ffind_file_name_handler fileio.c:324 > > #6 0x1006dbe5c in openp lread.c:1911 > > #7 0x1006d8844 in Fload lread.c:1302 > > #8 0x1006e1af0 in save_match_data_load lread.c:1630 > > #9 0x10064f8cc in load_with_autoload_queue eval.c:2269 > > #10 0x10067d2f8 in Frequire fns.c:3274 > > Forget to copy the part where it is freed: > > freed by thread T0 here: > #0 0x103332de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4) > #1 0x100985e38 in rpl_free free.c:48 > #2 0x1005b71a4 in lisp_free alloc.c:1038 > #3 0x1005cbda4 in compact_small_strings alloc.c:2191 > #4 0x1005c9f24 in sweep_strings alloc.c:2072 > #5 0x1005bd028 in gc_sweep alloc.c:7397 > #6 0x1005bb178 in garbage_collect alloc.c:6245 > #7 0x1005ba694 in maybe_garbage_collect alloc.c:6090 > #8 0x1006505ac in maybe_gc lisp.h:5624 > #9 0x100648ffc in Ffuncall eval.c:2972 > #10 0x10064bcd0 in internal_condition_case_n eval.c:1555 > #11 0x1000cdc8c in safe__call xdisp.c:3026 > #12 0x1000cdfc4 in safe__call1 xdisp.c:3062 > #13 0x1001d6404 in prepare_menu_bars xdisp.c:13572 > #14 0x1000f2340 in redisplay_internal xdisp.c:16523 > #15 0x100108f34 in redisplay xdisp.c:16105 > #16 0x10088fa84 in -[EmacsView layoutSublayersOfLayer:] nsterm.m:8662 > #17 0x1900a9624 in CA::Layer::layout_if_needed(CA::Transaction*)+0x224 (QuartzCore:arm64e+0x20624) > #18 0x1901f661c in CA::Context::commit_transaction(CA::Transaction*, double, double*)+0x1c0 (QuartzCore:arm64e+0x16d61c) > #19 0x19008b4c8 in CA::Transaction::commit()+0x2bc (QuartzCore:arm64e+0x24c8) > #20 0x18bee1698 in __62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke+0x12c (AppKit:arm64e+0x1ac698) > #21 0x18c646754 in ___NSRunLoopObserverCreateWithHandler_block_invoke+0x3c (AppKit:arm64e+0x911754) > #22 0x1892101a0 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__+0x20 (CoreFoundation:arm64e+0x841a0) > #23 0x18920fff0 in __CFRunLoopDoObservers+0x24c (CoreFoundation:arm64e+0x83ff0) > #24 0x18920f524 in __CFRunLoopRun+0x300 (CoreFoundation:arm64e+0x83524) > #25 0x18920ea80 in CFRunLoopRunSpecific+0x254 (CoreFoundation:arm64e+0x82a80) > #26 0x191e4e334 in RunCurrentEventLoopInMode+0x120 (HIToolbox:arm64e+0x32334) > #27 0x191e4dfc0 in ReceiveNextEventCommon+0x140 (HIToolbox:arm64e+0x31fc0) > #28 0x191e4de64 in _BlockUntilNextEventMatchingListInModeWithFilter+0x44 (HIToolbox:arm64e+0x31e64) > #29 0x18bd76518 in _DPSNextEvent+0x358 (AppKit:arm64e+0x41518) So it was freed by GC, which probably relocated string data or something. But I don't understand the relation between these two backtraces: was the one that accessed a freed string called by the one which triggered GC? IOW, what is the relation between the call to 'require', which ended up calling re_match_2_internal, and the call to prepare_menu_bars, which triggered GC? re_search gets Lisp strings as its arguments, so unless GC was called while the regexp search was in progress, I cannot understand how this could happen. Is there any way to know which argument of re_match_2_internal was used to access the free'd heap? From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 24 11:08:28 2022 Received: (at 58042) by debbugs.gnu.org; 24 Sep 2022 15:08:28 +0000 Received: from localhost ([127.0.0.1]:44963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oc6lR-0005QX-5t for submit@debbugs.gnu.org; Sat, 24 Sep 2022 11:08:28 -0400 Received: from mail-ed1-f41.google.com ([209.85.208.41]:44938) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oc6lP-0005QL-Sr for 58042@debbugs.gnu.org; Sat, 24 Sep 2022 11:08:20 -0400 Received: by mail-ed1-f41.google.com with SMTP id x21so3688287edd.11 for <58042@debbugs.gnu.org>; Sat, 24 Sep 2022 08:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=xQ9o9Yjwujb98WNo8RZOkCmDGb708zY/0j/dSnxyLEA=; b=gnjgEvVCW5sj7/xt1TQBEanaVVQUORF69W+KmTzLOKuDM04itRbcDOdNcNzqX1oomS QLWB/KYVPdWpsiIRTyN4YtzYCtvaoZzo3OyzUpgLet+oucQR4kPKcYEEtOSxpeetBgT2 c2vM4amZ8Nqvf0d/qQW0AQcftCMw3KUnAQQcuEjmjCH5Ars9NjfwZ4fTwLJLS2RbJl8r pJWmLibd2sHrxL7wzsM8Y7sXzYdyjh6YzFzW4VV3MWgy5hd5KfWAuPF1iPabStSnx9P+ S5ds2E2NsQz7XO/myqesOm6sSYvN+RsUsv1yg/8+Bpk4T1uvRewjWJgnGUpgGyGUWtSw htfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=xQ9o9Yjwujb98WNo8RZOkCmDGb708zY/0j/dSnxyLEA=; b=KZPEoKZkgYZwfyJUo26GNw4sfiUtN1BuUO3w3d91zjA7gZTFG5eyz95eGk7Rgs7zPe ZSaxfDXFibgBXaFOgalKsHffsevNhJ0CH+a3xecASD3czOIiP0X5IOsAThlYEdpU9Mlc inb0wgEkvErhT/czf/PiFAo9MiPQRrBf8bjEWAMn1IgqwodpPy9xiSHa0m48nijMLPYg QWUTKqhHg9+UnGIPtjQ5Fhr3WJklvHRfbqAPehaMe6Rg7EH9ytghg3esJk5uliF0Q6b9 DvIGvPpDZs8dsCgnmlsmCJx1p3b5mgwY/vpD91q3gyjqJOYFyjnLGyvuy6CaxKFvlolZ KNUA== X-Gm-Message-State: ACrzQf1xuZkNiohDNEGDQvE5fqocxEBNyV9Gh/LrxGlSmllHh+B0qkJG 7Xp59KlVR8HsDvRnoA7HL0Gx5Gvu7qw= X-Google-Smtp-Source: AMsMyM50ueqdY63ND3km4yRc2RJxkEqbMxbu/wa2wZmAfrdn5DH8Rqp+juOfFEZQucpIu2nYQYNTKg== X-Received: by 2002:a05:6402:2711:b0:451:327a:365f with SMTP id y17-20020a056402271100b00451327a365fmr13414649edd.315.1664032093603; Sat, 24 Sep 2022 08:08:13 -0700 (PDT) Received: from Mini.fritz.box (p4fe3a935.dip0.t-ipconnect.de. [79.227.169.53]) by smtp.gmail.com with ESMTPSA id j1-20020a17090623e100b0077a201f6d1esm5493141ejg.87.2022.09.24.08.08.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Sep 2022 08:08:12 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <835yhcom6g.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 24 Sep 2022 17:56:55 +0300") References: <835yhcom6g.fsf@gnu.org> Date: Sat, 24 Sep 2022 17:08:12 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Date: Sat, 24 Sep 2022 16:17:20 +0200 >>=20 >> Gerd M=C3=B6llmann writes: >>=20 >> > =3D=3D79227=3D=3DERROR: AddressSanitizer: heap-use-after-free on addre= ss >> > 0x00011f81e7d1 at pc 0x0001005825c4 bp 0x00016fdcf370 sp >> > 0x00016fdcf368 >> > READ of size 1 at 0x00011f81e7d1 thread T0 >> > #0 0x1005825c0 in re_match_2_internal regex-emacs.c:4352 >> > #1 0x10057e5cc in rpl_re_search_2 regex-emacs.c:3383 >> > #2 0x10057d1c4 in rpl_re_search regex-emacs.c:3177 >> > #3 0x10056115c in fast_string_match_internal search.c:492 >> > #4 0x1005045c0 in fast_string_match lisp.h:4818 >> > #5 0x100504018 in Ffind_file_name_handler fileio.c:324 >> > #6 0x1006dbe5c in openp lread.c:1911 >> > #7 0x1006d8844 in Fload lread.c:1302 >> > #8 0x1006e1af0 in save_match_data_load lread.c:1630 >> > #9 0x10064f8cc in load_with_autoload_queue eval.c:2269 >> > #10 0x10067d2f8 in Frequire fns.c:3274 >>=20 >> Forget to copy the part where it is freed: >>=20 >> freed by thread T0 here: >> #0 0x103332de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib= :arm64e+0x3ede4) >> #1 0x100985e38 in rpl_free free.c:48 >> #2 0x1005b71a4 in lisp_free alloc.c:1038 >> #3 0x1005cbda4 in compact_small_strings alloc.c:2191 >> #4 0x1005c9f24 in sweep_strings alloc.c:2072 >> #5 0x1005bd028 in gc_sweep alloc.c:7397 >> #6 0x1005bb178 in garbage_collect alloc.c:6245 >> #7 0x1005ba694 in maybe_garbage_collect alloc.c:6090 >> #8 0x1006505ac in maybe_gc lisp.h:5624 >> #9 0x100648ffc in Ffuncall eval.c:2972 >> #10 0x10064bcd0 in internal_condition_case_n eval.c:1555 >> #11 0x1000cdc8c in safe__call xdisp.c:3026 >> #12 0x1000cdfc4 in safe__call1 xdisp.c:3062 >> #13 0x1001d6404 in prepare_menu_bars xdisp.c:13572 >> #14 0x1000f2340 in redisplay_internal xdisp.c:16523 >> #15 0x100108f34 in redisplay xdisp.c:16105 >> #16 0x10088fa84 in -[EmacsView layoutSublayersOfLayer:] nsterm.m:8662 >> #17 0x1900a9624 in CA::Layer::layout_if_needed(CA::Transaction*)+0x2= 24 (QuartzCore:arm64e+0x20624) >> #18 0x1901f661c in >> CA::Context::commit_transaction(CA::Transaction*, double, >> double*)+0x1c0 (QuartzCore:arm64e+0x16d61c) >> #19 0x19008b4c8 in CA::Transaction::commit()+0x2bc (QuartzCore:arm64= e+0x24c8) >> #20 0x18bee1698 in __62+[CATransaction(NSCATransaction) >> NS_setFlushesWithDisplayLink]_block_invoke+0x12c >> (AppKit:arm64e+0x1ac698) >> #21 0x18c646754 in ___NSRunLoopObserverCreateWithHandler_block_invok= e+0x3c (AppKit:arm64e+0x911754) >> #22 0x1892101a0 in >> __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__+0x20 >> (CoreFoundation:arm64e+0x841a0) >> #23 0x18920fff0 in __CFRunLoopDoObservers+0x24c (CoreFoundation:arm6= 4e+0x83ff0) >> #24 0x18920f524 in __CFRunLoopRun+0x300 (CoreFoundation:arm64e+0x835= 24) >> #25 0x18920ea80 in CFRunLoopRunSpecific+0x254 (CoreFoundation:arm64e= +0x82a80) >> #26 0x191e4e334 in RunCurrentEventLoopInMode+0x120 (HIToolbox:arm64e= +0x32334) >> #27 0x191e4dfc0 in ReceiveNextEventCommon+0x140 (HIToolbox:arm64e+0x= 31fc0) >> #28 0x191e4de64 in _BlockUntilNextEventMatchingListInModeWithFilter+= 0x44 (HIToolbox:arm64e+0x31e64) >> #29 0x18bd76518 in _DPSNextEvent+0x358 (AppKit:arm64e+0x41518) > > So it was freed by GC, which probably relocated string data or > something. But I don't understand the relation between these two > backtraces: was the one that accessed a freed string called by the one > which triggered GC? IOW, what is the relation between the call to > 'require', which ended up calling re_match_2_internal, and the call to > prepare_menu_bars, which triggered GC? I don't understand that part either. > re_search gets Lisp strings as its arguments, so unless GC was called > while the regexp search was in progress, I cannot understand how this > could happen. Right, that's what I also think. See also my other mail. > Is there any way to know which argument of re_match_2_internal was > used to access the free'd heap? I can't figure it out from the code, and LLDB got the segmentation fault, so I can't look. Maybe Stefan can figure that out. But in general, I think the small string compaction could be a serious problem here, as soon as a GC happens while the regexp machine holds pointers. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 24 11:24:32 2022 Received: (at 58042) by debbugs.gnu.org; 24 Sep 2022 15:24:32 +0000 Received: from localhost ([127.0.0.1]:44982 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oc716-00080l-6U for submit@debbugs.gnu.org; Sat, 24 Sep 2022 11:24:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47796) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oc710-00080V-Q8 for 58042@debbugs.gnu.org; Sat, 24 Sep 2022 11:24:30 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42864) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oc70v-0001U6-Je; Sat, 24 Sep 2022 11:24:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Pr+rJBye9anl0OGCfY4CIV0qdLI//gFpgsWxmIakZAE=; b=jo/C+IEp13oK8Mau9cub JNutXtTUJASFXuA9Pn6ydZQq+vBwcEbiBhtiAvKl88Dijyju87nPgmUTVQY4qz6rxdiGPOaKkJN5m 0tone5qlFbzQyP2lDXliEpWrdKUwQJWEktgwqGJBYHEEPcZXd23Pbh6l2JXUX1+rATg5setnzKdZG rFkNYA+8kUG2vLirDvxSFh8WVND5VS17L30Z5aQCaosoznrLW3sYnF+lW2+xIneXPn0/Y6Pp+Exmf 83nFacgzcMM6XIo61FmkL4ktavfEYojcDpqT2/52QAlQU68pJWYRZIbOD8VCDbpbXiNqC5wApCRB6 CbaOkumJdC6UvA==; Received: from [87.69.77.57] (port=4846 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oc70u-00039d-Rb; Sat, 24 Sep 2022 11:24:21 -0400 Date: Sat, 24 Sep 2022 18:24:07 +0300 Message-Id: <831qs0okx4.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Sat, 24 Sep 2022 17:08:12 +0200) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <835yhcom6g.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 58042@debbugs.gnu.org > Date: Sat, 24 Sep 2022 17:08:12 +0200 > > But in general, I think the small string compaction could be a serious > problem here, as soon as a GC happens while the regexp machine holds > pointers. What is the path from regexp match to GC? The GC was triggered by redisplay, but how did redisplay start while regexp match was in progress? Do you see any code in regexp that could trigger redisplay? From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 25 01:50:33 2022 Received: (at 58042) by debbugs.gnu.org; 25 Sep 2022 05:50:33 +0000 Received: from localhost ([127.0.0.1]:45688 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocKX9-0007gg-5x for submit@debbugs.gnu.org; Sun, 25 Sep 2022 01:50:33 -0400 Received: from mail-ed1-f51.google.com ([209.85.208.51]:33349) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocKX4-0007g3-5y for 58042@debbugs.gnu.org; Sun, 25 Sep 2022 01:50:30 -0400 Received: by mail-ed1-f51.google.com with SMTP id b35so5162645edf.0 for <58042@debbugs.gnu.org>; Sat, 24 Sep 2022 22:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=/Ni02pfISPhDeHCuP12keLMrbC8Qw3wyTH4LRrF5e6s=; b=PysotDSVrqyZ5bIbSF966XYktkqI+gHNpE/uAAQcSyumD/BnNcpnj2I7fHPkkKLssF IoTG860sTaxryq3jdOYPSsrjfn76Fw6qDKHttiYbHDzOfWecTzPSXnecNzZBF1gVrlFh rfDJo/c5xjJr+I+lta6EGztETI8B1nwzOwS55444Gb0rQxjWgm5KaZGm2lu+2RIVky77 8lJtR/uRCIWXNcYbvxhllEyfV/SEypFoiNykD+i/DOl48yAJEIhrMitD6CrB5iE5q6U2 SjZwis9zzXVijFZQ8eM8+yP6iDkxJpSjr0djIB7jbS3ezevwy1208eiXjD/sjldsfGzR BgAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=/Ni02pfISPhDeHCuP12keLMrbC8Qw3wyTH4LRrF5e6s=; b=1nrHKl1nG47zrLNKMGa4x8Sx/3MM3/oDHFL1t8AO4n6p8D/TbReXt8xX4TLjxyBXDS wmCankCismof6nEHF/fGZH/trO2jj3HSGjU5JGq1zRXDlMUOPnYjphn79mtDUPBL3peE 0bJfnd6DzK621BuG+7YpqAmRwopkYH9c+jco9+w10ZJWgu2MOUYwxbRdAPtxSwsp5VW6 cYnn/kHxIDMEEYH+EziCBymLQElg8rvqgpeyPbo04bgo7gqHB3BfRqP2VdXW1SCdjbwe X/n7sRoqIZLSS/qugzgVTOoH+KkUOgGVH5zOb12dT2lJzdEQnHbt6EhC//L5nd7wv4MQ PlNg== X-Gm-Message-State: ACrzQf25gW2EYfQxkLmnBMaBWXy4IpCrZ3ssXFqdtSbuNHSCXyouOX87 HeRWXPtGcCYHfdl4tEJizdZh3mRJ64o= X-Google-Smtp-Source: AMsMyM45KmPP+DUmkNhZleiauj6IYHObuewQIsrbXW5YeckHngglT0hYJf1PDIdXP9Ei4J7sfP26jQ== X-Received: by 2002:a05:6402:1d86:b0:457:e84:f0e with SMTP id dk6-20020a0564021d8600b004570e840f0emr4453562edb.241.1664085019692; Sat, 24 Sep 2022 22:50:19 -0700 (PDT) Received: from Mini.fritz.box (pd9e362ca.dip0.t-ipconnect.de. [217.227.98.202]) by smtp.gmail.com with ESMTPSA id b11-20020a170906194b00b0072ed9efc9dfsm6384898eje.48.2022.09.24.22.50.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Sep 2022 22:50:18 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <831qs0okx4.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 24 Sep 2022 18:24:07 +0300") References: <835yhcom6g.fsf@gnu.org> <831qs0okx4.fsf@gnu.org> Date: Sun, 25 Sep 2022 07:50:17 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: 58042@debbugs.gnu.org >> Date: Sat, 24 Sep 2022 17:08:12 +0200 >>=20 >> But in general, I think the small string compaction could be a serious >> problem here, as soon as a GC happens while the regexp machine holds >> pointers. > > What is the path from regexp match to GC? I think since bug#56108 it's safe to say that a GC can happen while matching. In that bug, a regexp_cache entry was "freed" by GC. > The GC was triggered by > redisplay, but how did redisplay start while regexp match was in > progress? Do you see any code in regexp that could trigger redisplay? I'm afraid, I don't follow. Why do you think redisplay comes into play here? Anyways, my working hypotheses currently goes like this: We match using some Lisp string S and get its data pointer, say D. Since D is not null, S must be a live string. (Actually I didn't check that this is still the case, but I think I've been setting s.data to null for free strings right from the start, and I can't imagine why anyone would change that.) Between the point we get D, and the point of the crash, a GC happens. We know in principle that a GC can happen while matching since bug#56108. I'm taking that as a given. The GC compacts strings and changes S's data pointer. After GC, S.data !=3D D. Now, ASAN knows that a struct sdata was allocated and freed in the past that contains S.data. Or perhaps better said S.data points into the part of the the freed struct sdata that ASAN checks. How can that hapoen? I have no idea, but that's the scenario I give the most credibility so far. WDYT? From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 25 02:33:06 2022 Received: (at 58042) by debbugs.gnu.org; 25 Sep 2022 06:33:06 +0000 Received: from localhost ([127.0.0.1]:45724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocLCM-0000Wl-Br for submit@debbugs.gnu.org; Sun, 25 Sep 2022 02:33:06 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46152) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocLCK-0000WF-HJ for 58042@debbugs.gnu.org; Sun, 25 Sep 2022 02:33:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49072) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocLCF-00079U-BV; Sun, 25 Sep 2022 02:32:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=PeO/Q5ZFH+Yg8dNpWuZXZ+XAVElDQE7JbVE7k1JVzmI=; b=W/In5Dt+H0bQ2J2APzw4 PAmbQ5sqkEqSW1PgzJ7O7lCwOlTBuRga9ThMqDlC1IY8TbiVfP2wxIxZthrDH/wzY2/fH/Q6+V9eQ uzhwYbzS2sbhK8NOpf34tqiVFn3MPv3tOs5jldFckxTz9922gCNBiMTrC+EXD/UvtOcCqn7K+cQ/z b755Z+XKlzoTT7ek2RyaT0taL2uNOAuYUwHOTTWlrA82SmjqD4hoUN07s9qDTp7NcjWuSo0vNsf6H s8FNff1tuoEIor1Z05ha+em9ZzO7CfBFh+pTDorld4z0j9t06RiASei2FVCpkDfyYWPTMSIa1is0p s83XCPfRBRXATQ==; Received: from [87.69.77.57] (port=4811 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocLCE-0007n1-5H; Sun, 25 Sep 2022 02:32:58 -0400 Date: Sun, 25 Sep 2022 09:32:46 +0300 Message-Id: <83mtaom0a9.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Sun, 25 Sep 2022 07:50:17 +0200) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <835yhcom6g.fsf@gnu.org> <831qs0okx4.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 58042@debbugs.gnu.org > Date: Sun, 25 Sep 2022 07:50:17 +0200 > > > The GC was triggered by > > redisplay, but how did redisplay start while regexp match was in > > progress? Do you see any code in regexp that could trigger redisplay? > > I'm afraid, I don't follow. Why do you think redisplay comes into play > here? Because of this part of your message in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58042#8: freed by thread T0 here: #0 0x103332de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4) #1 0x100985e38 in rpl_free free.c:48 #2 0x1005b71a4 in lisp_free alloc.c:1038 #3 0x1005cbda4 in compact_small_strings alloc.c:2191 #4 0x1005c9f24 in sweep_strings alloc.c:2072 #5 0x1005bd028 in gc_sweep alloc.c:7397 #6 0x1005bb178 in garbage_collect alloc.c:6245 #7 0x1005ba694 in maybe_garbage_collect alloc.c:6090 #8 0x1006505ac in maybe_gc lisp.h:5624 #9 0x100648ffc in Ffuncall eval.c:2972 #10 0x10064bcd0 in internal_condition_case_n eval.c:1555 #11 0x1000cdc8c in safe__call xdisp.c:3026 #12 0x1000cdfc4 in safe__call1 xdisp.c:3062 #13 0x1001d6404 in prepare_menu_bars xdisp.c:13572 #14 0x1000f2340 in redisplay_internal xdisp.c:16523 #15 0x100108f34 in redisplay xdisp.c:16105 AFAIU, this says that the GC which freed the string data was caused by safe__call1 inside prepare_menu_bars, which was called from redisplay_internal. > Anyways, my working hypotheses currently goes like this: > > We match using some Lisp string S and get its data pointer, say D. > Since D is not null, S must be a live string. > > (Actually I didn't check that this is still the case, but I think I've > been setting s.data to null for free strings right from the start, and I > can't imagine why anyone would change that.) > > Between the point we get D, and the point of the crash, a GC happens. > We know in principle that a GC can happen while matching since > bug#56108. I'm taking that as a given. The GC compacts strings and > changes S's data pointer. > > After GC, S.data != D. Yes, but I have difficulty with the fact that GC was caused by redisplay, and redisplay cannot be invoked while we are in re_match_2_internal, AFAIK. So something else is missing here (or maybe I'm misinterpreting the ASAN report you posted). From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 25 03:07:09 2022 Received: (at 58042) by debbugs.gnu.org; 25 Sep 2022 07:07:09 +0000 Received: from localhost ([127.0.0.1]:45753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocLjJ-0001PZ-Gu for submit@debbugs.gnu.org; Sun, 25 Sep 2022 03:07:09 -0400 Received: from mail-ej1-f46.google.com ([209.85.218.46]:47019) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocLjH-0001PM-D9 for 58042@debbugs.gnu.org; Sun, 25 Sep 2022 03:07:08 -0400 Received: by mail-ej1-f46.google.com with SMTP id bj12so8192360ejb.13 for <58042@debbugs.gnu.org>; Sun, 25 Sep 2022 00:07:07 -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=KaFaqLz6GbTMPJ2RE05gWfNjtXibriKYP73gAy/hEDs=; b=cc8p3jtoDDGhtJ53Z4BSrPWA54gvKnrqZ8V6jy920LLSesJxvZc7K678rzaus/nE7M CwJeLuk5gi5P3MS7hEYeQHITu+r3a9HZHwG1gf5aCIuWzC7sbZTg9oHpmVWvL3+2fXsi hMPXM+UdbT7URoiU6E0d3SazzVpiVHxO6LTCJdnBhmvoU5bsm93qPuBjSnmldS5jFuWA stKj6BKCYgdx/GJXWINAUr3gr3Ei1oAj1uwMUKdwccRIA4m6KrqRoVBqcWuh9J6RIRst jENFtV+K+uf+2Zm/CN39IstAyeFmlwb2V514KIy5MbXmNNkrDPgof/sRqvqNgpbbHLoB vOyA== 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=KaFaqLz6GbTMPJ2RE05gWfNjtXibriKYP73gAy/hEDs=; b=yglgEDhTTWiJaBywta0YBnI6ySzpjBOBRFkMUd8jvluy6mRTzKzPB2cGMsXNPMvtEh fwZ4jtLZbN8P/ccud8iYcrlyqjebS27r7G+3S4kye06M6kl98dQ4G+sNFgtjLN4wsORX XAPxiyBxoNMGdCVxGT54xPQdcvQtszmJT1YqqGkodH/toc+QWecDzaiYeMv9W9HLpl/G 2IL8RGN6BWXLuM3sekKPw+8OhhzSYtbuWgpMkK0RZ6bZ411wqAEr6IWhOIJKbq7SBy3c Oktkewa4Gff6wZot7nYRR5wx/ivUemeY3hFFMU8FnujeZ/3/Id/OtLImqYQgeaVFqaY4 Svqw== X-Gm-Message-State: ACrzQf0nkhWf/wZFqAIlFXc2+Z5AgPlPd+LvoL3tNVZQ2XOcJRPs2Jvu FSGNqU8mGk6Iv37DV/o+ywaOlitSOcM= X-Google-Smtp-Source: AMsMyM60ZuCIG+oacEBNEI/zWNJXlHbgJDSn+BnHjQuocE/7P5mJtMY+T6Kxl2Ol1XWkq6KUBp5Xvw== X-Received: by 2002:a17:907:6285:b0:781:ad26:7b53 with SMTP id nd5-20020a170907628500b00781ad267b53mr14134884ejc.273.1664089621054; Sun, 25 Sep 2022 00:07:01 -0700 (PDT) Received: from Mini.fritz.box (pd9e362ca.dip0.t-ipconnect.de. [217.227.98.202]) by smtp.gmail.com with ESMTPSA id p16-20020a1709060e9000b007707ec25071sm6344703ejf.220.2022.09.25.00.06.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Sep 2022 00:07:00 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <83mtaom0a9.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 25 Sep 2022 09:32:46 +0300") References: <835yhcom6g.fsf@gnu.org> <831qs0okx4.fsf@gnu.org> <83mtaom0a9.fsf@gnu.org> Date: Sun, 25 Sep 2022 09:06:59 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > #14 0x1000f2340 in redisplay_internal xdisp.c:16523 > #15 0x100108f34 in redisplay xdisp.c:16105 > > AFAIU, this says that the GC which freed the string data was caused by > safe__call1 inside prepare_menu_bars, which was called from > redisplay_internal. Ah, okay! Sorry, I didn't remember that redisplay on the stack. Please see below. > Yes, but I have difficulty with the fact that GC was caused by > redisplay, and redisplay cannot be invoked while we are in > re_match_2_internal, AFAIK. So something else is missing here (or > maybe I'm misinterpreting the ASAN report you posted). The second and third backtrace that ASAN displays (freed by, and previously allocated) are not backtraces directly involved in the crash. They display some history related to the pointer that causes the crash. When something is allocated or freed, ASAN records callstacks that show from where that happens. Also, in the case pf free, it somehow arranges that accessing that freed memory leads to a signal. I think it uses VM page protection for that. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 25 04:08:37 2022 Received: (at 58042) by debbugs.gnu.org; 25 Sep 2022 08:08:37 +0000 Received: from localhost ([127.0.0.1]:45819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocMgn-0002zl-9n for submit@debbugs.gnu.org; Sun, 25 Sep 2022 04:08:37 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36282) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocMgl-0002zW-HG for 58042@debbugs.gnu.org; Sun, 25 Sep 2022 04:08:35 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48884) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocMgg-00036W-1h; Sun, 25 Sep 2022 04:08:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Rx5eo0kYxWD05kcerBIi7wLBrehim2LvNjKx0Tnjb8U=; b=D2R98oXllncgTSdb37lz rEHHohbNWX+awUE/11NzbtmIhAZlKYJBJkDU2nkARu2UZOhi8Ys2snoZHEtVq9bds7h5FZX9v1ZDr pVI0TcLE3fmj7t3KwhWu7l3fdPdHh4S8nzFTL5RAtGjQiSUfSX7wt+o6PqlxPsR+ZOzJHnDR7f6s7 hIhKjkMnC5uv4bxVEkhtiObHq+RUcaqNI5/DBExE1VOjXvyp9T9rCR87Uq+5gegaiy4a1xD1G0e5s iT2F5H75uujAmS5aMSVVogO+tb9FuyvTBf6Didvdx0kgFJEyThDfMTx2qCFja4iALQvA0/iJ4K94y PkuJU3HqcPlP0g==; Received: from [87.69.77.57] (port=2691 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocMgf-0004PZ-8H; Sun, 25 Sep 2022 04:08:29 -0400 Date: Sun, 25 Sep 2022 11:08:18 +0300 Message-Id: <83illbnafh.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Sun, 25 Sep 2022 09:06:59 +0200) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <835yhcom6g.fsf@gnu.org> <831qs0okx4.fsf@gnu.org> <83mtaom0a9.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 58042@debbugs.gnu.org > Date: Sun, 25 Sep 2022 09:06:59 +0200 > > Eli Zaretskii writes: > > > #14 0x1000f2340 in redisplay_internal xdisp.c:16523 > > #15 0x100108f34 in redisplay xdisp.c:16105 > > > > AFAIU, this says that the GC which freed the string data was caused by > > safe__call1 inside prepare_menu_bars, which was called from > > redisplay_internal. > > Ah, okay! Sorry, I didn't remember that redisplay on the stack. Please > see below. > > > Yes, but I have difficulty with the fact that GC was caused by > > redisplay, and redisplay cannot be invoked while we are in > > re_match_2_internal, AFAIK. So something else is missing here (or > > maybe I'm misinterpreting the ASAN report you posted). > > The second and third backtrace that ASAN displays (freed by, and > previously allocated) are not backtraces directly involved in the crash. > They display some history related to the pointer that causes the crash. So you are saying that the backtrace I quoted, which shows that GC that freed the string was triggered by redisplay, is NOT the GC which actually freed the particular string involved in the read-from-freed-heap? If so, where's the backtrace showing the GC that did free/relocate this particular string? IOW, I think I'm now confused wrt what exactly the ASAN data tells us. Can you perhaps help me understand that, quoting the relevant backtraces as you go? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 25 04:28:59 2022 Received: (at 58042) by debbugs.gnu.org; 25 Sep 2022 08:28:59 +0000 Received: from localhost ([127.0.0.1]:45848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocN0V-0003UZ-Gb for submit@debbugs.gnu.org; Sun, 25 Sep 2022 04:28:59 -0400 Received: from mail-ed1-f41.google.com ([209.85.208.41]:38732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocN0S-0003UH-9q for 58042@debbugs.gnu.org; Sun, 25 Sep 2022 04:28:58 -0400 Received: by mail-ed1-f41.google.com with SMTP id 30so5313337edw.5 for <58042@debbugs.gnu.org>; Sun, 25 Sep 2022 01:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=yMn+sg2PYJaj85kki3QDwuBo1BRxYykWhSJwouN/C04=; b=RiedE73yWIjdvYZBdQ+UkXpZykPovHUJ0vAZz3qWoEegsRXtpS0dWTYbh98ThlkGY1 ffzramyzuvBU4oMQFpmM/RFDLg7TOPgCzsjS7LRzQo/8gUD6AFAMWOlfmadvd5bWaWu0 zo17v1kWFQV0nYHPsbLQ+lPhmtwq3rgbvk4xY2EDnbLv9OCoRt6T3/LHQCSy+2psoojE T6aDI19570p6nNe/Mvj6gKFD3z3wnK9pIDRigVjZ7Hp+OYA0q88cB2b/2RsZMktuAj/k Xfv2LjVzcYlcBqpk+qr0EHpuCO6mhK5vadMUrZDOPertgiSqwCTIJ83qLM9dDZK9wyBI ipAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=yMn+sg2PYJaj85kki3QDwuBo1BRxYykWhSJwouN/C04=; b=DtbicuDYkM6+GZJYhTrTwKEBW9VqS1e724yMasY+k9tOI5Nezv1e8MQlUJdEAoQXmR IX1b5LneRCL14iMuvZy5V5Re6jISlbKIMefthk9sD+5XQbjcC98/qfkuTUPM8e01O/dN XUsI/6nxrJCfoB7I+r2lp2//ctO0+jHab7J5PqjJ1c7xZTDwUFmvRM0H4LFS1S9HmK3/ GVv0galj1/zH6WWp6AaRHfY63CeYhoUOFGZoJjze/ftCRixlkFonqJVIgOjMtSXJBB/R tJigp4iKC77GxuELDux1ubt4Z5Va9on3jRp+27+2Ry/bDDqJTJxNq6FLf93GcMw/daXh pSSg== X-Gm-Message-State: ACrzQf2FTRk6ReKulNLbBfSMJmGKeL81YDy9AwDeLl8ez6U+4iMC35Xa 6Wgzm7D/V2EylilSnUNi58FJj/1FNG4= X-Google-Smtp-Source: AMsMyM6RYGByMmkGcStWsdrXRCfbTglBD0cEZeAOOUQTdhQeft7ccsmFo9CKIWAAcA7doJNUeF+XKQ== X-Received: by 2002:aa7:da08:0:b0:456:ea2b:3ce3 with SMTP id r8-20020aa7da08000000b00456ea2b3ce3mr7741464eds.181.1664094530002; Sun, 25 Sep 2022 01:28:50 -0700 (PDT) Received: from Mini.fritz.box (pd9e362ca.dip0.t-ipconnect.de. [217.227.98.202]) by smtp.gmail.com with ESMTPSA id ed6-20020a056402294600b0045722259584sm1222466edb.86.2022.09.25.01.28.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Sep 2022 01:28:49 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <83illbnafh.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 25 Sep 2022 11:08:18 +0300") References: <835yhcom6g.fsf@gnu.org> <831qs0okx4.fsf@gnu.org> <83mtaom0a9.fsf@gnu.org> <83illbnafh.fsf@gnu.org> Date: Sun, 25 Sep 2022 10:28:48 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: 58042@debbugs.gnu.org >> Date: Sun, 25 Sep 2022 09:06:59 +0200 >>=20 >> Eli Zaretskii writes: >>=20 >> > #14 0x1000f2340 in redisplay_internal xdisp.c:16523 >> > #15 0x100108f34 in redisplay xdisp.c:16105 >> > >> > AFAIU, this says that the GC which freed the string data was caused by >> > safe__call1 inside prepare_menu_bars, which was called from >> > redisplay_internal. >>=20 >> Ah, okay! Sorry, I didn't remember that redisplay on the stack. Please >> see below. >>=20 >> > Yes, but I have difficulty with the fact that GC was caused by >> > redisplay, and redisplay cannot be invoked while we are in >> > re_match_2_internal, AFAIK. So something else is missing here (or >> > maybe I'm misinterpreting the ASAN report you posted). >>=20 >> The second and third backtrace that ASAN displays (freed by, and >> previously allocated) are not backtraces directly involved in the crash. >> They display some history related to the pointer that causes the crash. > > So you are saying that the backtrace I quoted, which shows that GC > that freed the string was triggered by redisplay, is NOT the GC which > actually freed the particular string involved in the > read-from-freed-heap? That's my working assumption, yes. > If so, where's the backtrace showing the GC > that did free/relocate this particular string? It's not there. > IOW, I think I'm now confused wrt what exactly the ASAN data tells us. > Can you perhaps help me understand that, quoting the relevant > backtraces as you go? That confueses me, too. Everything in the hypothesis seems to work, except that I can't explain how the pointer S.data, to use that term again, can end up pointing into memory that ASAN has page-protected. - S must be live at the beginning of the match, otherwise S.data =3D=3D NULL. - The freeing of the struct sblock during rediplay happens in the same thread as the match where we crash. So it must have happened before the match. So, the question seems to be what scenario would create a live string that points into a freed sdata struct. I'm out of ideas, and close to giving up. Any alternative theories are of course more than welcome. I'm just seeking something that maybe can be falsified. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 25 04:44:26 2022 Received: (at 58042) by debbugs.gnu.org; 25 Sep 2022 08:44:26 +0000 Received: from localhost ([127.0.0.1]:45865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocNFS-0003sW-Io for submit@debbugs.gnu.org; Sun, 25 Sep 2022 04:44:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40990) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocNFN-0003sF-55 for 58042@debbugs.gnu.org; Sun, 25 Sep 2022 04:44:24 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50452) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocNFH-000810-TD; Sun, 25 Sep 2022 04:44:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=1gwCrpcVH/zqEuKCD+Hb96gUiLXBYN4+um8NYhme9Pc=; b=Jjl+Lu42Q15VR4quDOnd sor0hY3r2+fxzr5n0oQ/nawqFYF3ayZG432Qml8AnhNvVNDlL2Kzo0ovGauH0tzW3KTzAdVsD3PxG 1FRQbCKMqQ8BOqSaFPlLccsMb1Wj2h2xtgKfr/U4srxTTniGCIHLZKrUjpRvjhQOMhzNSNgRKmhMU NVDbr9M6ACC9LoNNhZJT5FlLbh9GIBX5CpHkKP9nYE+G4A5Hof/KMASeLj/5RFL8YJr0nCKgjVSyi ipJtCzIeH6Y3/w2md+iNnLN4g6sFwZdLDnx8lzqdDd1WWZn9zofKyIHGhlcjvqZhS1dFBBohLl0Qt duJsvzk+2C3fhQ==; Received: from [87.69.77.57] (port=1301 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocNF2-0003In-Rd; Sun, 25 Sep 2022 04:44:01 -0400 Date: Sun, 25 Sep 2022 11:43:48 +0300 Message-Id: <83fsgfn8sb.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Sun, 25 Sep 2022 10:28:48 +0200) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <835yhcom6g.fsf@gnu.org> <831qs0okx4.fsf@gnu.org> <83mtaom0a9.fsf@gnu.org> <83illbnafh.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 58042@debbugs.gnu.org > Date: Sun, 25 Sep 2022 10:28:48 +0200 > > So, the question seems to be what scenario would create a live string > that points into a freed sdata struct. That sounds highly improbable to me. But stranger things have happened... From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 26 01:13:16 2022 Received: (at 58042) by debbugs.gnu.org; 26 Sep 2022 05:13:16 +0000 Received: from localhost ([127.0.0.1]:48934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocgQe-0002a0-Gk for submit@debbugs.gnu.org; Mon, 26 Sep 2022 01:13:16 -0400 Received: from mail-ej1-f48.google.com ([209.85.218.48]:36571) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocgQb-0002Zk-U0 for 58042@debbugs.gnu.org; Mon, 26 Sep 2022 01:13:14 -0400 Received: by mail-ej1-f48.google.com with SMTP id 13so11618160ejn.3 for <58042@debbugs.gnu.org>; Sun, 25 Sep 2022 22:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=0qWr3B3Mt+2u6ySxlIguIZmivhATAVvth3KC3Ydgdqk=; b=DBp7BcaSTsd9sfuN9VgznOYRJoHvuQttztI0QSuFXt0H3sOGWXlr3RYmyO/aQuJeNw 9BBHxGUPUDYD29mcko54wqKgHyYx6ksEhY9wQ1kE1Hz9jKHW57l0bTL51BCaQjxcJUGb hB3n9GqzW0q67dOqF3b7ylB5ruamy4ioKLwhvdw2Rua2knnxF3/+5D117msM1+YLaRng sZznvigiiOSPecYXHrNIZh7yWsg5PqhxANNusra9z+VmNFbvvxZSylD3WO643jXQSbJV tOiPdPGajAyRCVOa9EC++dly4iKJAnmJglTEr8mP4S7vxSnkHBW79naPodHMAYm6Srw9 yLPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=0qWr3B3Mt+2u6ySxlIguIZmivhATAVvth3KC3Ydgdqk=; b=dlfPpsGow3+mj6dKltVlaxxMYkBlComDw+b07oV4p6tyjWZ/ZYs0aiaLmEmF9o8MsV IY5ZujHbDw6Slxzy2SVa+ZsmgfnQ1cMQIebcA8BmUqBptKIKRQveYC70Fhxw5zhg8PkQ Mhr2p3UtYUWmtpvBRmhgUhWywgPX2sz+bpTYgSH2DhlqJVLtrOD5vtAQLSRUiY+8/gFf jyVMwYRamVE87WbBF3ktbQos0AsLnkzE/O5vtvxmDYThe1/nxi/KXQvTuOkq0be4l4ut aSQfP2PESTUOjenzd08I04UhwL21ZvYVqTqFhpHN60xE55o5Sa9lGrcibtDfkroITgXn Sn+A== X-Gm-Message-State: ACrzQf1q28IhlXCPFSiKKWsuVqtj/76wvkYO5hDo2H+yLVRudMKcTPor 2TqosSjEysdtZAKKNfM+qpDzsdehi2Q= X-Google-Smtp-Source: AMsMyM7kiJJsoL6dnIdrsnMisbP5tIB9P9qEXJkqMoUs8OVnwgBPQd7Q3tzRS4+J39MAvGuHVhFM8Q== X-Received: by 2002:a17:906:8a53:b0:781:6ee9:db96 with SMTP id gx19-20020a1709068a5300b007816ee9db96mr16164844ejc.301.1664169187328; Sun, 25 Sep 2022 22:13:07 -0700 (PDT) Received: from Mini.fritz.box (pd9e36b1b.dip0.t-ipconnect.de. [217.227.107.27]) by smtp.gmail.com with ESMTPSA id p4-20020a170906604400b0073de0506745sm7776998ejj.197.2022.09.25.22.13.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Sep 2022 22:13:06 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <83fsgfn8sb.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 25 Sep 2022 11:43:48 +0300") References: <835yhcom6g.fsf@gnu.org> <831qs0okx4.fsf@gnu.org> <83mtaom0a9.fsf@gnu.org> <83illbnafh.fsf@gnu.org> <83fsgfn8sb.fsf@gnu.org> Date: Mon, 26 Sep 2022 07:13:05 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: 58042@debbugs.gnu.org >> Date: Sun, 25 Sep 2022 10:28:48 +0200 >>=20 >> So, the question seems to be what scenario would create a live string >> that points into a freed sdata struct. > > That sounds highly improbable to me. But stranger things have > happened... Yeah :-/. In the meantime, and in an attempt to get some more information, I've made me a script that starts Emacs in LLDB, with my init file, and exits Emacs after a delay, and then does things in LLDB depending on what happened. I left that script running over night, and the result wasn't very helpful. After almost 2 hours of running, I got an ASAN error in copyRect:(NSRect)srcRect to:(NSPoint)dest, nsterm.m. And LLDB crashed again. This is with HEAD 568920a5b703e80c43e1b6f31778ea5776218a1e. I meanwhile wonder what that all means. An "invalid display" that isn't reproducible, a crash in regexp, a crash in copyRect, and then the crashes in LLDB itself. I think I'll let that sit for a bit. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 04 10:33:58 2022 Received: (at 58042) by debbugs.gnu.org; 4 Oct 2022 14:33:58 +0000 Received: from localhost ([127.0.0.1]:54905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofizc-0000E3-TL for submit@debbugs.gnu.org; Tue, 04 Oct 2022 10:33:58 -0400 Received: from mail-ej1-f49.google.com ([209.85.218.49]:37825) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofiza-0000Dq-MA for 58042@debbugs.gnu.org; Tue, 04 Oct 2022 10:33:56 -0400 Received: by mail-ej1-f49.google.com with SMTP id a26so29300176ejc.4 for <58042@debbugs.gnu.org>; Tue, 04 Oct 2022 07:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:to:from:from:to:cc:subject:date; bh=mNTqedbSjkONJKcAKArkLfhZmClsM3kHu4HainLvlxs=; b=jzXCgmlqulAI3X3M3X5BlEFNQ38I4QbbgJiqNzY3hmfmnXFcDNO8LIghcgXhF2aRP9 xRUXrmMa3OyKk8/fGF5cVux/AXetsvob8Y+9O7gLMVlxlAM7E5YOgEZ/BTmB+b10J4M/ ClWqJvTf3MeJ9WYZKNsnwnWRMIQPTElVuaGrReE5UdLFxDR6I10GKnpkwaiUebNtka39 6w8CbXHXhlaWguJheGHiXAHQdmdn7xfUvSVZ0AGlcWd3EFzWT/odqSMr5V7JUv5Liin8 I9sNiMO064A2HJFyFWZiFim651eFUjt2oVf/7o4ikwPa6fscHevJAZg6aAJ3kZE8LZqP TurA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:to:from:x-gm-message-state:from:to :cc:subject:date; bh=mNTqedbSjkONJKcAKArkLfhZmClsM3kHu4HainLvlxs=; b=MluUhNKmrKWQhEV0bP7tMfi308g+nds2KHVSthcyT5ghUsIHvd9OzkuquscQAtR8dU Egf50xB6zuu2BjQ9P+KAg770sbmZOBox3XtlDPDVixhUpcmy8C/3hT2RsuxvOKzI+Vnv GHaiz/JvxXKGbRmYD+5fRDThxawFJfvdGmxwBFvg5VUScUDcl/Ym3qvAU4NUFj60c/uK W+EFqXXbkm7+jT1cX4P89BPsVWoeZYP1nYlwbAHl7ezJa1/ziAP64efHrL1r/7Fk8XDi RSyImHiKCxXJuLRu2svKJCHJnqXCbgp4YcTvFQ2/5w6ZHESlEITS2rM1OoCHUrDN+v5s 7Zww== X-Gm-Message-State: ACrzQf0GuEW9quAfUFRQmZuL25z8nTnJmdM2abfDT37KlvnlVb5+UaTi wgCycvY3gpMsO/pkaxBRNi+xbcZZjpQ= X-Google-Smtp-Source: AMsMyM4IstQJcDJBcw4xN/r0XfM06Xo4kLQs35TaR/jKh2hwiyJeHknBTcRnwvJPODReIz5bgA6rKg== X-Received: by 2002:a17:906:cc10:b0:77b:df70:efd2 with SMTP id ml16-20020a170906cc1000b0077bdf70efd2mr19732344ejb.590.1664894028021; Tue, 04 Oct 2022 07:33:48 -0700 (PDT) Received: from Mini.fritz.box (pd9e36907.dip0.t-ipconnect.de. [217.227.105.7]) by smtp.gmail.com with ESMTPSA id du1-20020a17090772c100b0073d71792c8dsm7149826ejc.180.2022.10.04.07.33.46 for <58042@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Oct 2022 07:33:47 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: 58042@debbugs.gnu.org Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Sat, 24 Sep 2022 15:45:39 +0200") References: Date: Tue, 04 Oct 2022 16:33:45 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: Happened again today when starting Emacs with my init filem and I can't make sense of it. And, of course,LLDB finally crashed :-(. (lldb) PLEASE submit a bug report to https://developer.apple.com/bug-report= ing/ and include the crash backtrace. Stack dump without symbol names (ensure you have llvm-symbolizer in your PA= TH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): 0 lldb 0x00000001041e55dc llvm::sys:= :PrintStackTrace(llvm::raw_ostream&, This is c3eb6c0563cc95b2134af9fe0ee6f304ddbb0480, which is from the noverlay branch. =3D=3D15586=3D=3DERROR: AddressSanitizer: heap-use-after-free on address 0x= 00011f90d0a1 at pc 0x000100582044 bp 0x00016fdc8290 sp 0x00016fdc8288 READ of size 1 at 0x00011f90d0a1 thread T0 #0 0x100582040 in re_match_2_internal regex-emacs.c:4328 #1 0x10057e2a4 in rpl_re_search_2 regex-emacs.c:3383 #2 0x10057ce9c in rpl_re_search regex-emacs.c:3177 #3 0x100560e34 in fast_string_match_internal search.c:492 #4 0x100504298 in fast_string_match lisp.h:4816 #5 0x100503cf0 in Ffind_file_name_handler fileio.c:324 #6 0x1006dbb34 in openp lread.c:1911 #7 0x1006d851c in Fload lread.c:1302 #8 0x1006e17c8 in save_match_data_load lread.c:1630 #9 0x10064f5a4 in load_with_autoload_queue eval.c:2269 #10 0x10067cfd0 in Frequire fns.c:3274 #11 0x100654630 in funcall_subr eval.c:3019 #12 0x10072e674 in exec_byte_code bytecode.c:809 #13 0x10072c238 in Fbyte_code bytecode.c:329 #14 0x100641c48 in eval_sub eval.c:2486 #15 0x1006e118c in readevalloop lread.c:2339 #16 0x1006d9d80 in Fload lread.c:1581 #17 0x1006e17c8 in save_match_data_load lread.c:1630 #18 0x10064f5a4 in load_with_autoload_queue eval.c:2269 #19 0x10067cfd0 in Frequire fns.c:3274 #20 0x100641c48 in eval_sub eval.c:2486 #21 0x1006f5a04 in readevalloop_eager_expand_eval lread.c:2154 #22 0x1006e117c in readevalloop lread.c:2337 #23 0x1006e29dc in Feval_buffer lread.c:2410 #24 0x100654900 in funcall_subr eval.c:3023 #25 0x10072e674 in exec_byte_code bytecode.c:809 #26 0x10065cd48 in fetch_and_exec_byte_code eval.c:3064 #27 0x100655570 in funcall_lambda eval.c:3136 #28 0x100653d48 in funcall_general eval.c:2927 #29 0x100648db4 in Ffuncall eval.c:2977 #30 0x1006de658 in call4 lisp.h:3317 #31 0x1006d96d0 in Fload lread.c:1477 #32 0x1006e17c8 in save_match_data_load lread.c:1630 #33 0x10064f5a4 in load_with_autoload_queue eval.c:2269 #34 0x10067cfd0 in Frequire fns.c:3274 #35 0x100641c48 in eval_sub eval.c:2486 #36 0x1006f5a04 in readevalloop_eager_expand_eval lread.c:2154 #37 0x1006e117c in readevalloop lread.c:2337 #38 0x1006e29dc in Feval_buffer lread.c:2410 #39 0x100654900 in funcall_subr eval.c:3023 #40 0x10072e674 in exec_byte_code bytecode.c:809 #41 0x10065cd48 in fetch_and_exec_byte_code eval.c:3064 #42 0x100655570 in funcall_lambda eval.c:3136 #43 0x100653d48 in funcall_general eval.c:2927 #44 0x100648db4 in Ffuncall eval.c:2977 #45 0x1006de658 in call4 lisp.h:3317 #46 0x1006d96d0 in Fload lread.c:1477 #47 0x1006e17c8 in save_match_data_load lread.c:1630 #48 0x10064f5a4 in load_with_autoload_queue eval.c:2269 #49 0x10067cfd0 in Frequire fns.c:3274 #50 0x100641c48 in eval_sub eval.c:2486 #51 0x1006f5a04 in readevalloop_eager_expand_eval lread.c:2154 #52 0x1006e117c in readevalloop lread.c:2337 #53 0x1006e29dc in Feval_buffer lread.c:2410 #54 0x100654900 in funcall_subr eval.c:3023 #55 0x10072e674 in exec_byte_code bytecode.c:809 #56 0x10065cd48 in fetch_and_exec_byte_code eval.c:3064 #57 0x100655570 in funcall_lambda eval.c:3136 #58 0x100653d48 in funcall_general eval.c:2927 #59 0x100648db4 in Ffuncall eval.c:2977 #60 0x1006de658 in call4 lisp.h:3317 #61 0x1006d96d0 in Fload lread.c:1477 #62 0x1006e17c8 in save_match_data_load lread.c:1630 #63 0x10064f5a4 in load_with_autoload_queue eval.c:2269 #64 0x10067cfd0 in Frequire fns.c:3274 #65 0x100641c48 in eval_sub eval.c:2486 #66 0x1006f5a04 in readevalloop_eager_expand_eval lread.c:2154 #67 0x1006e117c in readevalloop lread.c:2337 #68 0x1006e29dc in Feval_buffer lread.c:2410 #69 0x100654900 in funcall_subr eval.c:3023 #70 0x10072e674 in exec_byte_code bytecode.c:809 #71 0x10065cd48 in fetch_and_exec_byte_code eval.c:3064 #72 0x100655570 in funcall_lambda eval.c:3136 #73 0x100653d48 in funcall_general eval.c:2927 #74 0x100648db4 in Ffuncall eval.c:2977 #75 0x1006de658 in call4 lisp.h:3317 #76 0x1006d96d0 in Fload lread.c:1477 #77 0x100641ed0 in eval_sub eval.c:2494 #78 0x100643134 in Fprogn eval.c:436 #79 0x100647a78 in Flet eval.c:1023 #80 0x1006411c8 in eval_sub eval.c:2433 #81 0x100643134 in Fprogn eval.c:436 #82 0x100655a94 in funcall_lambda eval.c:3216 #83 0x100651410 in apply_lambda eval.c:3086 #84 0x100642a50 in eval_sub eval.c:2570 #85 0x1006f5a04 in readevalloop_eager_expand_eval lread.c:2154 #86 0x1006e117c in readevalloop lread.c:2337 #87 0x1006e29dc in Feval_buffer lread.c:2410 #88 0x100654900 in funcall_subr eval.c:3023 #89 0x10072e674 in exec_byte_code bytecode.c:809 #90 0x10065cd48 in fetch_and_exec_byte_code eval.c:3064 #91 0x100655570 in funcall_lambda eval.c:3136 #92 0x100653d48 in funcall_general eval.c:2927 #93 0x100648db4 in Ffuncall eval.c:2977 #94 0x1006de658 in call4 lisp.h:3317 #95 0x1006d96d0 in Fload lread.c:1477 #96 0x100654900 in funcall_subr eval.c:3023 #97 0x10072e674 in exec_byte_code bytecode.c:809 #98 0x10065cd48 in fetch_and_exec_byte_code eval.c:3064 #99 0x100655570 in funcall_lambda eval.c:3136 #100 0x100651410 in apply_lambda eval.c:3086 #101 0x10064251c in eval_sub eval.c:2527 #102 0x10064fb8c in Feval eval.c:2343 #103 0x1004524b0 in top_level_2 keyboard.c:1141 #104 0x10064b100 in internal_condition_case eval.c:1471 #105 0x1004523c4 in top_level_1 keyboard.c:1149 #106 0x10064988c in internal_catch eval.c:1194 #107 0x100417d64 in command_loop keyboard.c:1109 #108 0x1004177f4 in recursive_edit_1 keyboard.c:719 #109 0x1004187b0 in Frecursive_edit keyboard.c:802 #110 0x100410988 in main emacs.c:2521 #111 0x101545088 in start+0x204 (dyld:arm64e+0x5088) 0x00011f90d0a1 is located 1953 bytes inside of 8184-byte region [0x00011f90= c900,0x00011f90e8f8) freed by thread T0 here: #0 0x103332de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:ar= m64e+0x3ede4) #1 0x100985df8 in rpl_free free.c:48 #2 0x1005b6e7c in lisp_free alloc.c:1038 #3 0x1005cba7c in compact_small_strings alloc.c:2191 #4 0x1005c9bfc in sweep_strings alloc.c:2072 #5 0x1005bcd00 in gc_sweep alloc.c:7397 #6 0x1005bae50 in garbage_collect alloc.c:6245 #7 0x1005ba36c in maybe_garbage_collect alloc.c:6090 #8 0x100650284 in maybe_gc lisp.h:5622 #9 0x100648cd4 in Ffuncall eval.c:2972 #10 0x10064b9a8 in internal_condition_case_n eval.c:1555 #11 0x1000cd964 in safe__call xdisp.c:3026 #12 0x1000cdc9c in safe__call1 xdisp.c:3062 #13 0x1001d60dc in prepare_menu_bars xdisp.c:13572 #14 0x1000f2018 in redisplay_internal xdisp.c:16523 #15 0x100108c0c in redisplay xdisp.c:16105 #16 0x10088fa44 in -[EmacsView layoutSublayersOfLayer:] nsterm.m:8662 #17 0x1900a9624 in CA::Layer::layout_if_needed(CA::Transaction*)+0x224 = (QuartzCore:arm64e+0x20624) #18 0x1901f661c in CA::Context::commit_transaction(CA::Transaction*, do= uble, double*)+0x1c0 (QuartzCore:arm64e+0x16d61c) #19 0x19008b4c8 in CA::Transaction::commit()+0x2bc (QuartzCore:arm64e+0= x24c8) #20 0x18bee1698 in __62+[CATransaction(NSCATransaction) NS_setFlushesWi= thDisplayLink]_block_invoke+0x12c (AppKit:arm64e+0x1ac698) #21 0x18c646754 in ___NSRunLoopObserverCreateWithHandler_block_invoke+0= x3c (AppKit:arm64e+0x911754) #22 0x1892101a0 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_F= UNCTION__+0x20 (CoreFoundation:arm64e+0x841a0) #23 0x18920fff0 in __CFRunLoopDoObservers+0x24c (CoreFoundation:arm64e+= 0x83ff0) #24 0x18920f524 in __CFRunLoopRun+0x300 (CoreFoundation:arm64e+0x83524) #25 0x18920ea80 in CFRunLoopRunSpecific+0x254 (CoreFoundation:arm64e+0x= 82a80) #26 0x191e4e334 in RunCurrentEventLoopInMode+0x120 (HIToolbox:arm64e+0x= 32334) #27 0x191e4dfc0 in ReceiveNextEventCommon+0x140 (HIToolbox:arm64e+0x31f= c0) #28 0x191e4de64 in _BlockUntilNextEventMatchingListInModeWithFilter+0x4= 4 (HIToolbox:arm64e+0x31e64) #29 0x18bd76518 in _DPSNextEvent+0x358 (AppKit:arm64e+0x41518) previously allocated by thread T0 here: #0 0x103332ca8 in wrap_malloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:= arm64e+0x3eca8) #1 0x1005ae5d4 in lmalloc alloc.c:1361 #2 0x1005afe60 in lisp_malloc alloc.c:994 #3 0x1005b0734 in allocate_string_data alloc.c:1889 #4 0x1005b18b0 in make_clear_multibyte_string alloc.c:2475 #5 0x1005b1348 in make_clear_string alloc.c:2443 #6 0x1005b23ec in make_uninit_string alloc.c:2454 #7 0x1005b2358 in make_unibyte_string alloc.c:2369 #8 0x1006dba68 in openp lread.c:1908 #9 0x1006d851c in Fload lread.c:1302 #10 0x1006e17c8 in save_match_data_load lread.c:1630 #11 0x10064f5a4 in load_with_autoload_queue eval.c:2269 #12 0x10067cfd0 in Frequire fns.c:3274 #13 0x100654630 in funcall_subr eval.c:3019 #14 0x10072e674 in exec_byte_code bytecode.c:809 #15 0x10072c238 in Fbyte_code bytecode.c:329 #16 0x100641c48 in eval_sub eval.c:2486 #17 0x1006e118c in readevalloop lread.c:2339 #18 0x1006d9d80 in Fload lread.c:1581 #19 0x1006e17c8 in save_match_data_load lread.c:1630 #20 0x10064f5a4 in load_with_autoload_queue eval.c:2269 #21 0x10067cfd0 in Frequire fns.c:3274 #22 0x100641c48 in eval_sub eval.c:2486 #23 0x1006f5a04 in readevalloop_eager_expand_eval lread.c:2154 #24 0x1006e117c in readevalloop lread.c:2337 #25 0x1006e29dc in Feval_buffer lread.c:2410 #26 0x100654900 in funcall_subr eval.c:3023 #27 0x10072e674 in exec_byte_code bytecode.c:809 #28 0x10065cd48 in fetch_and_exec_byte_code eval.c:3064 #29 0x100655570 in funcall_lambda eval.c:3136 SUMMARY: AddressSanitizer: heap-use-after-free regex-emacs.c:4328 in re_mat= ch_2_internal Shadow bytes around the buggy address: 0x007023f419c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x007023f419d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x007023f419e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x007023f419f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x007023f41a00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd =3D>0x007023f41a10: fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd 0x007023f41a20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x007023f41a30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x007023f41a40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x007023f41a50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x007023f41a60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb =3D=3D15586=3D=3DABORTING (lldb) AddressSanitizer report breakpoint hit. Use 'thread info -s' to get = extended information about the report. (lldb) xbacktrace (unsigned char *) data =3D 0x0000000100a205e0 "require" (unsigned char *) data =3D 0x0000000100a25940 "byte-code" (unsigned char *) data =3D 0x0000000100a205e0 "require" (unsigned char *) data =3D 0x0000000100a24000 "eval-buffer" (unsigned char *) data =3D 0x0000000107e7d013 "load-with-code-conversion" (unsigned char *) data =3D 0x0000000100a205e0 "require" (unsigned char *) data =3D 0x0000000100a24000 "eval-buffer" (unsigned char *) data =3D 0x0000000107e7d013 "load-with-code-conversion" (unsigned char *) data =3D 0x0000000100a205e0 "require" (unsigned char *) data =3D 0x0000000100a24000 "eval-buffer" (unsigned char *) data =3D 0x0000000107e7d013 "load-with-code-conversion" (unsigned char *) data =3D 0x0000000100a205e0 "require" (unsigned char *) data =3D 0x0000000100a24000 "eval-buffer" (unsigned char *) data =3D 0x0000000107e7d013 "load-with-code-conversion" (unsigned char *) data =3D 0x0000000100a1dac0 "load" (unsigned char *) data =3D 0x0000000100a1d760 "let" (unsigned char *) data =3D 0x0000000105c184b0 "chemacs-load-user-init" (unsigned char *) data =3D 0x0000000100a24000 "eval-buffer" (unsigned char *) data =3D 0x0000000107e7d013 "load-with-code-conversion" (unsigned char *) data =3D 0x0000000100a1dac0 "load" (unsigned char *) data =3D 0x0000000107e7ee82 "startup--load-user-init-file" (unsigned char *) data =3D 0x0000000107e7f852 "command-line" (unsigned char *) data =3D 0x0000000107e80b37 "normal-top-level" frame #5: 0x0000000100582044 emacs`re_match_2_internal(bufp=3D0x00000001011= 1ace8, string1=3D0x0000000000000000, size1=3D0, string2=3D"/Users/gerd/.con= fig/emacs.d.default/elpa/magit-section-20220901.331/puny.dylib", size2=3D78= , pos=3D0, regs=3D0x0000000000000000, stop=3D78) at regex-emacs.c:4328:15 4325 DEBUG_PRINT ("EXECUTING anychar.\n"); 4326=09 4327 PREFETCH (); -> 4328 buf_ch =3D RE_STRING_CHAR_AND_LENGTH (d, buf_charlen, 4329 target_multibyte); 4330 buf_ch =3D TRANSLATE (buf_ch); 4331 if (buf_ch =3D=3D '\n') (lldb)=20 frame #6: 0x000000010057e2a8 emacs`rpl_re_search_2(bufp=3D0x000000010111ace= 8, str1=3D0x0000000000000000, size1=3D0, str2=3D"/Users/gerd/.config/emacs.= d.default/elpa/magit-section-20220901.331/puny.dylib", size2=3D78, startpos= =3D0, range=3D0, regs=3D0x0000000000000000, stop=3D78) at regex-emacs.c:338= 3:13 3380 && !bufp->can_be_null) 3381 return -1; 3382=09 -> 3383 val =3D re_match_2_internal (bufp, string1, size1, string2, s= ize2, 3384 startpos, regs, stop); 3385=09 3386 if (val >=3D 0) (lldb) down frame #5: 0x0000000100582044 emacs`re_match_2_internal(bufp=3D0x00000001011= 1ace8, string1=3D0x0000000000000000, size1=3D0, string2=3D"/Users/gerd/.con= fig/emacs.d.default/elpa/magit-section-20220901.331/puny.dylib", size2=3D78= , pos=3D0, regs=3D0x0000000000000000, stop=3D78) at regex-emacs.c:4328:15 4325 DEBUG_PRINT ("EXECUTING anychar.\n"); 4326=09 4327 PREFETCH (); -> 4328 buf_ch =3D RE_STRING_CHAR_AND_LENGTH (d, buf_charlen, 4329 target_multibyte); 4330 buf_ch =3D TRANSLATE (buf_ch); 4331 if (buf_ch =3D=3D '\n') (lldb) p d (re_char *) $285 =3D 0x000000011f90d0a1 "magit-section-20220901.331/puny.dy= lib" frame #10: 0x0000000100503cf4 emacs`Ffind_file_name_handler(filename=3D(str= uct Lisp_String *) $318 =3D 0x000000011f6ec4c0, operation=3D(struct Lisp_Sy= mbol *) $321 =3D 0x00000001010ec310) at fileio.c:324:24 321 operations =3D Fget (handler, Qoperations); 322=20=09 323 if (STRINGP (string) -> 324 && (match_pos =3D fast_string_match (string, filename)) > pos 325 && (NILP (operations) || ! NILP (Fmemq (operation, operation= s)))) 326 { 327 Lisp_Object tem; (lldb) p filename (Lisp_Object) $322 =3D 0x000000011f6ec4c4 (struct Lisp_String *) $324 =3D 0= x000000011f6ec4c0 (lldb) p *$324 (struct Lisp_String) $325 =3D { u =3D { s =3D { size =3D 78 size_byte =3D -1 intervals =3D NULL data =3D 0x000000011f5d2f38 "/Users/gerd/.config/emacs.d.default/elpa= /magit-section-20220901.331/puny.dylib" } next =3D 0x000000000000004e gcaligned =3D 'N' } } (lldb) p string (Lisp_Object) $326 =3D 0x000000011ce990c4 (struct Lisp_String *) $328 =3D 0= x000000011ce990c0 (lldb) p *$328 (struct Lisp_String) $329 =3D { u =3D { s =3D { size =3D 313 size_byte =3D -1 intervals =3D NULL data =3D 0x000000011cdce9f0 "\\`\\(.+\\.\\(?:7z\\|CAB\\|LZH\\|MSU\\|Z= IP\\|a\\(?:pk\\|r\\)\\|c\\(?:ab\\|pio\\|rate\\)\\|de\\(?:b\\|pot\\)\\|e\\(?= :pub\\|xe\\)\\|iso\\|jar\\|lzh\\|m\\(?:su\\|tree\\)\\|od[bfgpst]\\|pax\\|r\= \(?:ar\\|pm\\)\\|shar\\|t\\(?:ar\\|bz\\|gz\\|lz\\|xz\\|zst\\)\\|warc\\|x\\(= ?:ar\\|p[is]\\)\\|zip\\)\\(?:\\.\\(?:Z\\|bz2\\|gz\\|l\\(?:rz\\|z\\(?:ma\\|[= 4o]\\)?\\)\\|uu\\|xz\\|zst\\)\\)?\\)\\(/.*\\)\\'" } next =3D 0x0000000000000139 gcaligned =3D '9' } } frame #8: 0x0000000100560e38 emacs`fast_string_match_internal(regexp=3D(str= uct Lisp_String *) $342 =3D 0x000000011ce990c0, string=3D(struct Lisp_Strin= g *) $344 =3D 0x000000011f6ec4c0, table=3D(struct Lisp_Symbol *) $347 =3D 0= x00000001010e5860) at search.c:492:19 489 struct regexp_cache *cache_entry 490 =3D compile_pattern (regexp, 0, table, 0, STRING_MULTIBYTE (str= ing)); 491 freeze_pattern (cache_entry); -> 492 ptrdiff_t val =3D re_search (&cache_entry->buf, SSDATA (string), 493 SBYTES (string), 0, 494 SBYTES (string), 0); 495 unbind_to (count, Qnil); (lldb) p cache_entry (regexp_cache *) $348 =3D 0x000000010111acc8 (lldb) p *cache_entry (regexp_cache) $349 =3D { next =3D NULL regexp =3D 0x000000011f6dbbc4 (struct Lisp_String *) $351 =3D 0x000000011= f6dbbc0 f_whitespace_regexp =3D NULL syntax_table =3D 0x0000000000000030 (struct Lisp_Symbol *) $354 =3D 0x000= 00001010e5890 buf =3D { buffer =3D 0x0000000108991b80 "\v\U00000006\U00000001\U00000003\U000000= 0e\U00000004" allocated =3D 648 used =3D 555 charset_unibyte =3D 1 fastmap =3D 0x000000010111ad28 "" translate =3D NULL re_nsub =3D 2 can_be_null =3D true regs_allocated =3D 0 fastmap_accurate =3D true used_syntax =3D false multibyte =3D false target_multibyte =3D false } fastmap =3D "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\= 0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\= 0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\= 0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0" posix =3D false busy =3D true } (lldb) p *$351=20 (struct Lisp_String) $355 =3D { u =3D { s =3D { size =3D 313 size_byte =3D -1 intervals =3D NULL data =3D 0x000000011f5cfd90 "\\`\\(.+\\.\\(?:7z\\|CAB\\|LZH\\|MSU\\|Z= IP\\|a\\(?:pk\\|r\\)\\|c\\(?:ab\\|pio\\|rate\\)\\|de\\(?:b\\|pot\\)\\|e\\(?= :pub\\|xe\\)\\|iso\\|jar\\|lzh\\|m\\(?:su\\|tree\\)\\|od[bfgpst]\\|pax\\|r\= \(?:ar\\|pm\\)\\|shar\\|t\\(?:ar\\|bz\\|gz\\|lz\\|xz\\|zst\\)\\|warc\\|x\\(= ?:ar\\|p[is]\\)\\|zip\\)\\(?:\\.\\(?:Z\\|bz2\\|gz\\|l\\(?:rz\\|z\\(?:ma\\|[= 4o]\\)?\\)\\|uu\\|xz\\|zst\\)\\)?\\)\\(/.*\\)\\'" } next =3D 0x0000000000000139 gcaligned =3D '9' } } From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 04 12:35:42 2022 Received: (at 58042) by debbugs.gnu.org; 4 Oct 2022 16:35:42 +0000 Received: from localhost ([127.0.0.1]:55035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofktS-0003FD-BJ for submit@debbugs.gnu.org; Tue, 04 Oct 2022 12:35:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59574) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofktQ-0003Ez-5T for 58042@debbugs.gnu.org; Tue, 04 Oct 2022 12:35:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53260) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofktK-0005RW-OZ; Tue, 04 Oct 2022 12:35:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=21/ZEOI3L5w9IKATjnvrAcHXobzH+IcY9QG9XAx8PIg=; b=LXd5tatr5WCzN8cQkqqd Lw9Hs8pG8IKLkyaC/wl+KPaBTu+WDAoDg//aX+x1CDNvZxYWUm/h9Td6iXlJiXsPU6hWn+8ehjObo rj2+iZOysGi5ZnmtM3AZogzrpn+/LlCKsOrLKI8xtSXTM4nysCu8Ku+iHrBo62SiWMjQeciko0vfm YT6CRgOo8Bnd7uISGXuxOtqrwADB0ajeqNZPgDjz689oC/jr9N7Evd+Jen+c92R9U0AGU/Mgo+yUq r+1aUWYHTvcjrFGhTW3ecVmJpQhKJ7bAKfuWYe7TyJ/FnEt4oQx0WYlukfx4TFjj8mc65+v4sL/kH o2WptKQh5xZEcQ==; Received: from [87.69.77.57] (port=4258 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofktK-00080T-7g; Tue, 04 Oct 2022 12:35:34 -0400 Date: Tue, 04 Oct 2022 19:35:30 +0300 Message-Id: <83edvnv965.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Tue, 04 Oct 2022 16:33:45 +0200) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Date: Tue, 04 Oct 2022 16:33:45 +0200 > > 0x00011f90d0a1 is located 1953 bytes inside of 8184-byte region [0x00011f90c900,0x00011f90e8f8) > freed by thread T0 here: > #0 0x103332de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4) > #1 0x100985df8 in rpl_free free.c:48 > #2 0x1005b6e7c in lisp_free alloc.c:1038 > #3 0x1005cba7c in compact_small_strings alloc.c:2191 > #4 0x1005c9bfc in sweep_strings alloc.c:2072 > #5 0x1005bcd00 in gc_sweep alloc.c:7397 > #6 0x1005bae50 in garbage_collect alloc.c:6245 > #7 0x1005ba36c in maybe_garbage_collect alloc.c:6090 > #8 0x100650284 in maybe_gc lisp.h:5622 > #9 0x100648cd4 in Ffuncall eval.c:2972 > #10 0x10064b9a8 in internal_condition_case_n eval.c:1555 > #11 0x1000cd964 in safe__call xdisp.c:3026 > #12 0x1000cdc9c in safe__call1 xdisp.c:3062 > #13 0x1001d60dc in prepare_menu_bars xdisp.c:13572 > #14 0x1000f2018 in redisplay_internal xdisp.c:16523 > #15 0x100108c0c in redisplay xdisp.c:16105 > #16 0x10088fa44 in -[EmacsView layoutSublayersOfLayer:] nsterm.m:8662 > #17 0x1900a9624 in CA::Layer::layout_if_needed(CA::Transaction*)+0x224 (QuartzCore:arm64e+0x20624) > #18 0x1901f661c in CA::Context::commit_transaction(CA::Transaction*, double, double*)+0x1c0 (QuartzCore:arm64e+0x16d61c) > #19 0x19008b4c8 in CA::Transaction::commit()+0x2bc (QuartzCore:arm64e+0x24c8) > #20 0x18bee1698 in __62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke+0x12c (AppKit:arm64e+0x1ac698) > #21 0x18c646754 in ___NSRunLoopObserverCreateWithHandler_block_invoke+0x3c (AppKit:arm64e+0x911754) > #22 0x1892101a0 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__+0x20 (CoreFoundation:arm64e+0x841a0) > #23 0x18920fff0 in __CFRunLoopDoObservers+0x24c (CoreFoundation:arm64e+0x83ff0) > #24 0x18920f524 in __CFRunLoopRun+0x300 (CoreFoundation:arm64e+0x83524) > #25 0x18920ea80 in CFRunLoopRunSpecific+0x254 (CoreFoundation:arm64e+0x82a80) > #26 0x191e4e334 in RunCurrentEventLoopInMode+0x120 (HIToolbox:arm64e+0x32334) > #27 0x191e4dfc0 in ReceiveNextEventCommon+0x140 (HIToolbox:arm64e+0x31fc0) > #28 0x191e4de64 in _BlockUntilNextEventMatchingListInModeWithFilter+0x44 (HIToolbox:arm64e+0x31e64) > #29 0x18bd76518 in _DPSNextEvent+0x358 (AppKit:arm64e+0x41518) Any idea how is the above related to the other two backtraces? Why don't I see 'main' at the top of the backtrace here? Can the sanitizer be asked to produce more than 30 backtrace frames? From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 00:38:11 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 04:38:11 +0000 Received: from localhost ([127.0.0.1]:55576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofwAd-0002Lr-1n for submit@debbugs.gnu.org; Wed, 05 Oct 2022 00:38:11 -0400 Received: from mail-ed1-f45.google.com ([209.85.208.45]:41954) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofwAZ-0002LP-Ju for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 00:38:09 -0400 Received: by mail-ed1-f45.google.com with SMTP id z97so21398718ede.8 for <58042@debbugs.gnu.org>; Tue, 04 Oct 2022 21:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=dumUcRMcHCvySp8pk5G+5NMXa5dfGePrVB2tZsvYR5U=; b=jeBdDoq1uRol9IXvB9MwDaJV21gsRroMaf57qCpkbrHs6tFYeVaIPPnvpIYdWiNCIH Sxxxidjwmxnx7+iJBo9SIUrR8CfK0ShP/5har97Bo4gVGBeiPPBeRmtb/SlozXzRkdRA QryAn6AiMhv7Aj34c1ZkesP7ycs1cwJEolcsivj6fx15HMZX7Sz7c+f/D2YKFxq9rkxL 6bWOukskHwMAh3mqOrv2QSJrxggbeMOss3SwdpbUVmOdNA2oKantDvQXUHVdjqtvGqN8 ppm53JcJKVJcuXDzghXQzhDplfgTN5Fn9AUP3DHOfr2RPjXRi3XfJCvXfVAIJZKfkj39 Orbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=dumUcRMcHCvySp8pk5G+5NMXa5dfGePrVB2tZsvYR5U=; b=nuUYdqYgF78Qt+5qh5+rIiaVyhRKN5YFPVWQcxi4JlwoNonE+Usa5fiop8ie6te+Rr t+PyLZsQo9HVaaz88ORdgZNhTspS6GqNFjQsGlI3bjoOmVzBgYzLDtcW8C6PyCcvOtHE bQYdCJtUEHIXOCNS4aHrT1jyxbUVS2WCJANTEDjiXwfRlAl4W+Bfsq9Dx21Qc65J5cld NN3aVU3xrJFUFa+51S+3NmJQYtkx8ih9Imof1/BVFjtERQo3sPSVOD8nQbt9FMTNFjtF S+/RVAN/aKwkhAT7BNvG/7VwSm7EHMroa975N8gfU+FJgJHacRed5GMqi9dteScgJsKG lC7A== X-Gm-Message-State: ACrzQf0H7RvXWohu07W4gUZ+FM1kZO4VPQ/s2WoSQcfcslAAYQhoR+Ej dU+0Hs1uUt0eUXn6r/OYW+ZzSO+QyGA= X-Google-Smtp-Source: AMsMyM5v5AA5JDfdwZQ3SL3FFngVXqSDt7tD/wlY0/7jeFXAU6j+0VvIBh16Pg+a1RNzz5il+0VV5w== X-Received: by 2002:a05:6402:2409:b0:456:f97b:3794 with SMTP id t9-20020a056402240900b00456f97b3794mr27006352eda.145.1664944680935; Tue, 04 Oct 2022 21:38:00 -0700 (PDT) Received: from Mini.fritz.box (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id l12-20020aa7c30c000000b00458898fe90asm2926416edq.5.2022.10.04.21.37.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Oct 2022 21:38:00 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <83edvnv965.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 04 Oct 2022 19:35:30 +0300") References: <83edvnv965.fsf@gnu.org> Date: Wed, 05 Oct 2022 06:37:58 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Date: Tue, 04 Oct 2022 16:33:45 +0200 >>=20 >> 0x00011f90d0a1 is located 1953 bytes inside of 8184-byte region [0x00011= f90c900,0x00011f90e8f8) >> freed by thread T0 here: >> #0 0x103332de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib= :arm64e+0x3ede4) >> #1 0x100985df8 in rpl_free free.c:48 >> #2 0x1005b6e7c in lisp_free alloc.c:1038 > > Any idea how is the above related to the other two backtraces? Why > don't I see 'main' at the top of the backtrace here? Can the > sanitizer be asked to produce more than 30 backtrace frames? The three backtraces are printed by the ASAN lib, with or without LLDB. >From top to bottom we're going into the past 1. Present =3D Where the problem was found with the pointer 2. Past =3D where the memory block was freed that the pointer is in. 3. Pre-Past =3D where block was allocated that is freed in (2) I don't know why the ASAN output in (1) stops after 30 frames. And I don't know if the 30 can be changed. But 30 for (2) and (3) seems reasonable to me. After all, this means 2 * 30 pointers most be recorded per allocated memory block, and that's a quite noticeable overhead, performance-wise. 30 looks like a heuristic. More make programs slower, less is less helpful. When running under LLDB, we stop at (1), and can see the full callstack, if we want, starting in the ASAN lib where it signals SIGABRT, and going up to main etc. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 02:16:22 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 06:16:22 +0000 Received: from localhost ([127.0.0.1]:55709 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofxhe-0007Hb-Ef for submit@debbugs.gnu.org; Wed, 05 Oct 2022 02:16:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofxhc-0007HF-Mx for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 02:16:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36464) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofxhX-0008FQ-14; Wed, 05 Oct 2022 02:16:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=njmtsM2eJrICeBAAh7qgJGop/o2B2FJFA/vptWYEK+c=; b=oDo+Ov7ofDEOEzd8vH2l +bRwhpZlsm9s7IyUN651wYEJZE64rVcdrpV+L/fF5XJMRenmL6PZB3wFT27h75ONnY0Q40EwdXr9y E4lBXSvXAis2HbCMR6pmAAjj95fCo1bhcnLkDaLB3KRlZmxlFEtmjJGjhxRzgn7VOfSPU3tI5l/cT Snqb1kXwphlZTp4F/Bcm94ro6grFqiLMO7lA3l/jHU9FpwwmJc9/2nhssVtbFXztkfr/r8NxE0Hli f7FdGzXcVUuDEgRRxyFP6gJ/+dF1DU7B8TCPBQsz+vy7OXcxppx7y6/TkkvpWmBXcBN1nKecAq980 k0tW4VM4HKQn2Q==; Received: from [87.69.77.57] (port=3478 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofxhP-0003cz-OC; Wed, 05 Oct 2022 02:16:14 -0400 Date: Wed, 05 Oct 2022 09:16:05 +0300 Message-Id: <83pmf6u76i.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Wed, 05 Oct 2022 06:37:58 +0200) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 58042@debbugs.gnu.org > Date: Wed, 05 Oct 2022 06:37:58 +0200 > > >From top to bottom we're going into the past > > 1. Present = Where the problem was found with the pointer > 2. Past = where the memory block was freed that the pointer is in. > 3. Pre-Past = where block was allocated that is freed in (2) > > I don't know why the ASAN output in (1) stops after 30 frames. And I > don't know if the 30 can be changed. But 30 for (2) and (3) seems > reasonable to me. After all, this means 2 * 30 pointers most be > recorded per allocated memory block, and that's a quite noticeable > overhead, performance-wise. 30 looks like a heuristic. More make > programs slower, less is less helpful. > > When running under LLDB, we stop at (1), and can see the full callstack, > if we want, starting in the ASAN lib where it signals SIGABRT, and going > up to main etc. 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? 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? And 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 02:59:01 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 06:59:01 +0000 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 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 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) 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) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <83pmf6u76i.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 05 Oct 2022 09:16:05 +0300") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> Date: Wed, 05 Oct 2022 08:58:51 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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? From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 03:22:45 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 07:22:45 +0000 Received: from localhost ([127.0.0.1]:55766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofyjs-0000Vn-PG for submit@debbugs.gnu.org; Wed, 05 Oct 2022 03:22:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35052) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofyjq-0000VZ-Bh for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 03:22:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48244) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofyjl-0007BC-4R; Wed, 05 Oct 2022 03:22:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=FHW9BKh3CxJXHKAVBiOzHcHdDz5md9UdoPhbnK/xa0s=; b=VaZcrUqvgsJNCycGZahb +Q0OryqFpdHz8OL+vNem0oSmQ/jaRDcH5HeORfrkESVNTHkQRo+EyXhArJG75ViF9p+v1ZaU4sstj ZWeSv7ru1Xralf35IMcDCvcCyazZSElCKQVTD+GS4rOmTgPqI9DPPjBt9vgS1HtwngY8GazQQCprj BCDkmXKf6J13J2floh/Q/TadBpR2m3ryrAUAdBbDxHejXU3a0ST9LTKypXE8Umvt/XPKHfRw/QWdr tXxTO2TmUKWomtBenAtqA7gDiBIBFFQ0tHr/7OE6IcNwAw2DnTV88Cerl623CF9XAFf8WOrTtdxDz k6j8fFZm7TvKQw==; Received: from [87.69.77.57] (port=3562 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofyjk-0003Ch-Jn; Wed, 05 Oct 2022 03:22:36 -0400 Date: Wed, 05 Oct 2022 10:22:34 +0300 Message-Id: <83mtaau43p.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?iso-8859-1?Q?M=F6llmann?= In-Reply-To: (message from Gerd =?iso-8859-1?Q?M=F6llmann?= on Wed, 05 Oct 2022 08:58:51 +0200) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 58042@debbugs.gnu.org > Date: Wed, 05 Oct 2022 08:58:51 +0200 > > Eli Zaretskii writes: > > > 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. That part is clear, but the "GC somehow ran" part is not, and that is the part which we must understand to fix the problem. The filename's SSDATA is passed to re_search as a C string, under the assumption that GC cannot happen while re_search runs. If that assumption is false, we need to understand exactly how and in what cases, because without that there's nothing we can do -- regex-emacs.c code deals explicitly only with C strings. IOW, this isn't the case like char *ptr = SSDATA (lisp_string); ... dereference (ptr); where GC can happen as part of "...". Those cases are easy to fix. But this is not that case. > > 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. You mean, a macOS event can be received asynchronously, and will interrupt some processing in C, like inside regex-emacs.c? If that can happen, no code in Emacs is safe, ever. I don't believe this is possible: we no longer process window-system events asynchronously, AFAIK, and for this very reason. But maybe macOS is different? In that case, either we should change the macOS code to avoid doing that, or we should have some means of blocking such "interrupts" around specific code fragments, akin to block_input. > 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. Yes, I've seen that it's the same thread. Having redisplay run from another thread would be a larger disaster. > Maybe someone knowing the Mac port has an idea if this can happen? I hope so. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 03:34:42 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 07:34:42 +0000 Received: from localhost ([127.0.0.1]:55780 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofyvS-0000pL-0c for submit@debbugs.gnu.org; Wed, 05 Oct 2022 03:34:42 -0400 Received: from mail-ed1-f47.google.com ([209.85.208.47]:39598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofyvN-0000p5-Ul for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 03:34:40 -0400 Received: by mail-ed1-f47.google.com with SMTP id y100so21298021ede.6 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 00:34:37 -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=QxEEo+OsL6tZUHLcltK7uQGRJ3iDPaFj13DIcG871Nk=; b=ZKXFc9cC/FDKExyTMGhp6iNCL23I4TXe0IUATN0eGI/jgD6ESRIbN25k9D/hJmuzVF LYpSfB31bRu0TKrYAuXSIiU75NlzcOiS5trreXG2kfgn05s2PvKAxbvsLKfPTtyY3xPP 9jassYlfv183S6f+bI/j9TXfCH13OeaVHSsMRnaPnTlg6JjTXBYlllg1V/p8J1zAVnxz dI9i6vWEgxnZT5WToXi2m0/emrFl8rX3twaxU6UFk7CdjR0Jcg7Eo0iL8JArvkvMp+z9 3Eb7OmDlKtl2H6HNDaXbMUYt2xDkKzSldBJIorGllXzc8ZVyBixhR8kcxG76eZ3N1Lnb KxCw== 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=QxEEo+OsL6tZUHLcltK7uQGRJ3iDPaFj13DIcG871Nk=; b=6bB9nvieN+J+a+FyAmNEus+3UOv/31aA2kT+jV8PAhyKsSQ6Q4+17wDfMh7HOLL11n Wq8kaRA+XWd8ssDn7Y0GqkSdsj4Wf9Bl3V4RuXc3uT60UoSRYsI2JUF63HujlWl4Fm/f +oy2lfD1hf749+d1Br89ufBLFWB6jArSb6m3NGyw/VoYNgpeAAn8hHqojHq4UYa88FDU fRVAyY5Q/OGxRWa1VqC6qGEuivztqIumgIUO3N4WDd5PYO52Hl3HXwNRVbyde3Q8HN54 QY4hSoBAZSEGnLh78i2tD7AsSATXn8WkTqL7I1KDDXjaft2F1fF1kpL0O7l4jtlNMiyG O60g== X-Gm-Message-State: ACrzQf0hEi45CloCLqES1Xj/p/xBtEBtbX4sMemmcG0QNqQ5WrYszE6c HYvUQGEr6a2zr9F2DvDVhdai/DmMPHSFLQ== X-Google-Smtp-Source: AMsMyM51/PU2H3kCMXIeFu34cSPsRJOQeS/GVCr32JG3ZQL9jYvd+TcKLRgdSYdESXzYKRMXRs4Tmw== X-Received: by 2002:a05:6402:500d:b0:459:3e56:e6f9 with SMTP id p13-20020a056402500d00b004593e56e6f9mr8912065eda.367.1664955271512; Wed, 05 Oct 2022 00:34:31 -0700 (PDT) Received: from Mini.fritz.box (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id z6-20020a1709060f0600b0078238c1c182sm1811889eji.222.2022.10.05.00.34.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 00:34:30 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <83mtaau43p.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 05 Oct 2022 10:22:34 +0300") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> Date: Wed, 05 Oct 2022 09:34:30 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> What I can see is that, apparently, redisplay got called because Emacs >> received a MacOS event, and did a prepare_menu_bars etc etc. > > You mean, a macOS event can be received asynchronously, and will > interrupt some processing in C, like inside regex-emacs.c? If it can, I don't know. But is the GC during redisplay is the one moving the string, that would be the consequence, I think. > If that can happen, no code in Emacs is safe, ever. I don't believe > this is possible: we no longer process window-system events > asynchronously, AFAIK, and for this very reason. But maybe macOS is > different? In that case, either we should change the macOS code to > avoid doing that, or we should have some means of blocking such > "interrupts" around specific code fragments, akin to block_input. Yeah. It would be good if that wouldn't happen ever, if it can. If it can't happen, then the GC in redisplay that we see is not directly related to all of this. and your question how redisplay can run while matching is also off the table, I think. I don't know a way how that could happen. But some GC must run and move strings around. I don't know how else to explain the invalid pointer. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 05:00:12 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 09:00:12 +0000 Received: from localhost ([127.0.0.1]:55847 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og0GB-0002y3-Oa for submit@debbugs.gnu.org; Wed, 05 Oct 2022 05:00:12 -0400 Received: from mail-ej1-f43.google.com ([209.85.218.43]:42694) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og0G8-0002wh-JD for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 05:00:11 -0400 Received: by mail-ej1-f43.google.com with SMTP id kg6so18703078ejc.9 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 02:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=JZPdpUCUxwg7xkUfcenyUjrJYNUz3urSiCTqfHbopFM=; b=dT6PGl9Kjd5FAMf9JbVKzC6DT0gAaBHnWpZClxOinDJ04miYy+4yny0w/xgM13FMeJ dbprE3SNay8Q2I6a98qbl1dJzL7gRegoNiivyclmPSiDmjfWiGdndGV2QRBk7QGV+uld j4dMM58Pf2KD92shV1HZTUAOghBMDIC+DPU8aTMb9Sk2169gmxkKECMr/82OH5GukKQJ nmRgLxr9J2cdG/8v9UY66gjRtrfLq5yax/P3WiV8sLm7MwRrI60iI9q/kgODtqUKenxf IwKkvAM5QpwMjbtLpQLGkIAojO2FlflE8ZqRUqY85ugg2bXzSFj/IMD3iDJBHkM1NfyH fkcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=JZPdpUCUxwg7xkUfcenyUjrJYNUz3urSiCTqfHbopFM=; b=YPaDVgz5nhCkGsw9gcs5wvjlsZ7Vf4RcuE3dwp9dFnfpq/uMHXpF1GHqUE392X3hyC FA9BFuWN9CniZuIeuenpB1KACQdv2cVVjPQsrYRF0/dtvrx4hJ1TUmj0ytF76EMUGvh8 GQCGSKMjy7zmACEmPNvzxjo75ModqgwBwJ35NdcFiRLBNA2FI8iyNH7K/9d9ZA8PqqyG HVpSEo4cmmPvAnayp0yDlsJnngaZSqQE8lKZkjZgJDrwE6tbmxFes64VC1GQ9djoCY6I jraCaaVsdCVkX/DdOQhqzL8S1PP7OqoXzDEeLUFtuppGAGZYNEUisFsQ2+m3s8nmxh0C xehw== X-Gm-Message-State: ACrzQf3wz53ZldCTKmFkcKGEeb6t2FGKPLTgcTxcSyMA4cu0EuDKKAFw gz5g5TvuGriB/fbxHTRhWFjjpZ4UAMWCSA== X-Google-Smtp-Source: AMsMyM7nXTKdBrbyz57KFOt6aCRrMHTNYJStJBdJX5bPHCPltKyWJl72ckHSxrVuRTo+YmjmqULNVA== X-Received: by 2002:a17:906:4fd4:b0:78d:1e4f:e69a with SMTP id i20-20020a1709064fd400b0078d1e4fe69amr4798745ejw.0.1664960402086; Wed, 05 Oct 2022 02:00:02 -0700 (PDT) Received: from Mini.fritz.box (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id b10-20020a17090630ca00b00770812e2394sm8207150ejb.160.2022.10.05.02.00.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 02:00:01 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Wed, 05 Oct 2022 09:34:30 +0200") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> Date: Wed, 05 Oct 2022 11:00:00 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Eli Zaretskii writes: > >>> What I can see is that, apparently, redisplay got called because Emacs >>> received a MacOS event, and did a prepare_menu_bars etc etc. >> >> You mean, a macOS event can be received asynchronously, and will >> interrupt some processing in C, like inside regex-emacs.c? > > If it can, I don't know. But is the GC during redisplay is the one > moving the string, that would be the consequence, I think. > >> If that can happen, no code in Emacs is safe, ever. I don't believe >> this is possible: we no longer process window-system events >> asynchronously, AFAIK, and for this very reason. But maybe macOS is >> different? In that case, either we should change the macOS code to >> avoid doing that, or we should have some means of blocking such >> "interrupts" around specific code fragments, akin to block_input. > > Yeah. It would be good if that wouldn't happen ever, if it can. I just got another ASAN error in a branch based on master. It looks completely different, but I find it eye-opening for our case. Look at this: =3D=3D45724=3D=3DERROR: AddressSanitizer: heap-use-after-free on address 0x= 000107130d00 at pc 0x0001002a4b04 bp 0x00016fd155e0 sp 0x00016fd155d8 READ of size 8 at 0x000107130d00 thread T0 #0 0x1002a4b00 in PSEUDOVECTORP lisp.h:1110 #1 0x1002a4b70 in SYMBOL_WITH_POS_P lisp.h:1122 #2 0x10025a620 in EQ lisp.h:1342 #3 0x100281198 in run_window_change_functions window.c:3964 #4 0x1000f1bac in redisplay_internal xdisp.c:16600 #5 0x100107ee0 in redisplay xdisp.c:16111 #6 0x10089366c in -[EmacsView layoutSublayersOfLayer:] nsterm.m:8661 #7 0x1900a9624 in CA::Layer::layout_if_needed(CA::Transaction*)+0x224 (= QuartzCore:arm64e+0x20624) #8 0x1901f661c in CA::Context::commit_transaction(CA::Transaction*, dou= ble, double*)+0x1c0 (QuartzCore:arm64e+0x16d61c) #9 0x19008b4c8 in CA::Transaction::commit()+0x2bc (QuartzCore:arm64e+0x= 24c8) #10 0x18bee1698 in __62+[CATransaction(NSCATransaction) NS_setFlushesWi= thDisplayLink]_block_invoke+0x12c (AppKit:arm64e+0x1ac698) #11 0x18c646754 in ___NSRunLoopObserverCreateWithHandler_block_invoke+0= x3c (AppKit:arm64e+0x911754) #12 0x1892101a0 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_F= UNCTION__+0x20 (CoreFoundation:arm64e+0x841a0) #13 0x18920fff0 in __CFRunLoopDoObservers+0x24c (CoreFoundation:arm64e+= 0x83ff0) #14 0x18920f524 in __CFRunLoopRun+0x300 (CoreFoundation:arm64e+0x83524) #15 0x18920ea80 in CFRunLoopRunSpecific+0x254 (CoreFoundation:arm64e+0x= 82a80) #16 0x191e4e334 in RunCurrentEventLoopInMode+0x120 (HIToolbox:arm64e+0x= 32334) #17 0x191e4dfc0 in ReceiveNextEventCommon+0x140 (HIToolbox:arm64e+0x31f= c0) #18 0x191e4de64 in _BlockUntilNextEventMatchingListInModeWithFilter+0x4= 4 (HIToolbox:arm64e+0x31e64) #19 0x18bd76518 in _DPSNextEvent+0x358 (AppKit:arm64e+0x41518) #20 0x18bd74e10 in -[NSApplication(NSEvent) _nextEventMatchingEventMask= :untilDate:inMode:dequeue:]+0x52c (AppKit:arm64e+0x3fe10) #21 0x18bd66fdc in -[NSApplication run]+0x250 (AppKit:arm64e+0x31fdc) #22 0x100870bd0 in -[EmacsApp run] nsterm.m:5799 #23 0x1008c7b2c in ns_read_socket_1 nsterm.m:4679 #24 0x1008ae550 in ns_read_socket nsterm.m:4697 #25 0x100437394 in gobble_input keyboard.c:7379 #26 0x100438bfc in handle_async_input keyboard.c:7610 #27 0x100438bdc in process_pending_signals keyboard.c:7624 #28 0x10064bd90 in probably_quit eval.c:1657 #29 0x10065fe6c in maybe_quit lisp.h:3737 #30 0x10066cb7c in Fmemq fns.c:1837 #31 0x100645de8 in FletX eval.c:936 There is a path from maybe_quit to redisplay, and didn't we have maybe_quit alreasy in the matcher code? Mind-boggling! From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 05:23:50 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 09:23:50 +0000 Received: from localhost ([127.0.0.1]:55871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og0d4-0003Xr-DK for submit@debbugs.gnu.org; Wed, 05 Oct 2022 05:23:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40552) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og0d2-0003Xd-4f for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 05:23:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40636) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og0cw-0003vU-Us; Wed, 05 Oct 2022 05:23:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=c3TSQ1xVUrp12rsmAIiehz01btu4dGQZ4BzCMC3IKo0=; b=sMWrR6VGYTuWYSL5Tpde ZbcrKg9n0Q2CcqSlALLbpiCpsetn8VnxZ5xHhT8oWpyQhuDFBGnmRSLj4cDrb8+k45/LnBFrC2Imk IveNkclzD3gpdYUZzqpl98ZZaq9/s9EJ5Uvq0OlIuGAUhbm7woL/ReUAslDgfW+qEzy1cJTUSSyR+ qcOXwg2N6u1hWURH2WmS63sTUUxFMweV2RpvcRj428cem+xr+ENAZjGZ2PNhGk6oUsuzQ+PZHvC4s qhlwefI5RHQaT8rUGDGNi2rg4P3JKm1uUFHrxeCp41DP65LbUIEixr8qepybL9W99sVtcNZf4t0re MMB70xPjCaieLw==; Received: from [87.69.77.57] (port=3766 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og0ce-0002Zq-Up; Wed, 05 Oct 2022 05:23:40 -0400 Date: Wed, 05 Oct 2022 12:23:20 +0300 Message-Id: <83ilkytyif.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Wed, 05 Oct 2022 11:00:00 +0200) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 58042@debbugs.gnu.org > Date: Wed, 05 Oct 2022 11:00:00 +0200 > > ==45724==ERROR: AddressSanitizer: heap-use-after-free on address 0x000107130d00 at pc 0x0001002a4b04 bp 0x00016fd155e0 sp 0x00016fd155d8 > READ of size 8 at 0x000107130d00 thread T0 > #0 0x1002a4b00 in PSEUDOVECTORP lisp.h:1110 > #1 0x1002a4b70 in SYMBOL_WITH_POS_P lisp.h:1122 > #2 0x10025a620 in EQ lisp.h:1342 > #3 0x100281198 in run_window_change_functions window.c:3964 > #4 0x1000f1bac in redisplay_internal xdisp.c:16600 > #5 0x100107ee0 in redisplay xdisp.c:16111 > #6 0x10089366c in -[EmacsView layoutSublayersOfLayer:] nsterm.m:8661 > #7 0x1900a9624 in CA::Layer::layout_if_needed(CA::Transaction*)+0x224 (QuartzCore:arm64e+0x20624) > #8 0x1901f661c in CA::Context::commit_transaction(CA::Transaction*, double, double*)+0x1c0 (QuartzCore:arm64e+0x16d61c) > #9 0x19008b4c8 in CA::Transaction::commit()+0x2bc (QuartzCore:arm64e+0x24c8) > #10 0x18bee1698 in __62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke+0x12c (AppKit:arm64e+0x1ac698) > #11 0x18c646754 in ___NSRunLoopObserverCreateWithHandler_block_invoke+0x3c (AppKit:arm64e+0x911754) > #12 0x1892101a0 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__+0x20 (CoreFoundation:arm64e+0x841a0) > #13 0x18920fff0 in __CFRunLoopDoObservers+0x24c (CoreFoundation:arm64e+0x83ff0) > #14 0x18920f524 in __CFRunLoopRun+0x300 (CoreFoundation:arm64e+0x83524) > #15 0x18920ea80 in CFRunLoopRunSpecific+0x254 (CoreFoundation:arm64e+0x82a80) > #16 0x191e4e334 in RunCurrentEventLoopInMode+0x120 (HIToolbox:arm64e+0x32334) > #17 0x191e4dfc0 in ReceiveNextEventCommon+0x140 (HIToolbox:arm64e+0x31fc0) > #18 0x191e4de64 in _BlockUntilNextEventMatchingListInModeWithFilter+0x44 (HIToolbox:arm64e+0x31e64) > #19 0x18bd76518 in _DPSNextEvent+0x358 (AppKit:arm64e+0x41518) > #20 0x18bd74e10 in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+0x52c (AppKit:arm64e+0x3fe10) > #21 0x18bd66fdc in -[NSApplication run]+0x250 (AppKit:arm64e+0x31fdc) > #22 0x100870bd0 in -[EmacsApp run] nsterm.m:5799 > #23 0x1008c7b2c in ns_read_socket_1 nsterm.m:4679 > #24 0x1008ae550 in ns_read_socket nsterm.m:4697 > #25 0x100437394 in gobble_input keyboard.c:7379 > #26 0x100438bfc in handle_async_input keyboard.c:7610 > #27 0x100438bdc in process_pending_signals keyboard.c:7624 > #28 0x10064bd90 in probably_quit eval.c:1657 > #29 0x10065fe6c in maybe_quit lisp.h:3737 > #30 0x10066cb7c in Fmemq fns.c:1837 > #31 0x100645de8 in FletX eval.c:936 > > There is a path from maybe_quit to redisplay, and didn't we have > maybe_quit alreasy in the matcher code? Mind-boggling! Ouch! This seems to be macOS-specific, though. So I guess we should do this dance around calls to maybe_quit in regex-emacs.c: specpdl_ref gc_count = inhibit_garbage_collection (); maybe_quit (); unbind_to (gc_count, Qnil); Or maybe even better, do this inside probably_quit (because who knows how many other callers of maybe_quit could be hit by this unexpected GC)? Can you try this? From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 06:14:15 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 10:14:15 +0000 Received: from localhost ([127.0.0.1]:55945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og1Pr-0004pf-98 for submit@debbugs.gnu.org; Wed, 05 Oct 2022 06:14:15 -0400 Received: from mail-ej1-f54.google.com ([209.85.218.54]:45806) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og1Po-0004pQ-Pm for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 06:14:13 -0400 Received: by mail-ej1-f54.google.com with SMTP id z23so17659868ejw.12 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 03:14:12 -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=ydEloL6XigaYyhk6YIuzlvI2iEXaBEjXg7qV/JL2nuk=; b=jCSbZhwkTO6vDkNxQS5UAwEqdp7B964UZYJid4pLrA4a5Q9nAmQDc+xa8ah/MMu8Pl 32TUYrkDz5Ipg5GsT3v+3Cb/Xx4du10AFBHCueh4c35EWiiLS5PqGwu0gwhvh/6jwWBp oEVhpD5yYbfqwznCLNw/3uzqi43oh/jgz/fhfc02oU1RHbIFuismnLIy8Vhw6IauhGlV Qm36KyV69nuxBUz9EVxREMs8B2yzHtcCJIm3jidymG6C/G7AFZ3mYLySrX77m0+KTcxJ jp3tz0iuQoEP5ByqKm0OLUlMPY1ji7ompURq7amcbaD3MaSKGWvljltOC0sqnVNxB+PG bbkw== 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=ydEloL6XigaYyhk6YIuzlvI2iEXaBEjXg7qV/JL2nuk=; b=A4+rsO080dFSJ9B6IpCLHdl9VSjko4KM2ODOq4MJBcDmyeMgGVvKfIKxQ47fHuEO9Y FhrZYgLCzwH3ZOufu93Ee0amDOLxQ6W2iX4Js8yS46e0eYUuXRjmVDh0+hAu04nmT/wS Jkyo0FitNp20VIuEgQrY3S4Mc1xTTW9Po2y7TYYw2+z2x/X5Fo83teoSxrJzwyRBFfVh ricXaBmy4Lre57drqSEHZv+YBJRJmsZtgNgRLuMWwQlk0h+I4CA/w3myzPKJsyJrdbPJ z3+1UvnlBWKmWnthjiVPYPVZOYM1vQFb/IkV3bwlvNj8OMxTowo83veF5uYMLTlpaM/A o8xQ== X-Gm-Message-State: ACrzQf1PX0gPVwupqyKYSoKJ0fBnrYY8ocZdSRvIs5QpgKC3ueQEB/rg 95iBjV/st1Q9FdLufjAB9xQ= X-Google-Smtp-Source: AMsMyM4AhkpthsJ2D8k+QJPeA6pqpU0AOdZJMczMjP+U3Lbx3MaTpL9Y1QcP4jb4CWvfTCrMfZVmrw== X-Received: by 2002:a17:907:80a:b0:783:2585:5d73 with SMTP id wv10-20020a170907080a00b0078325855d73mr23068373ejb.642.1664964846625; Wed, 05 Oct 2022 03:14:06 -0700 (PDT) Received: from Mini.fritz.box (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id t26-20020a170906179a00b0078082f95e5csm8228526eje.204.2022.10.05.03.14.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 03:14:05 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <83ilkytyif.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 05 Oct 2022 12:23:20 +0300") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> Date: Wed, 05 Oct 2022 12:14:04 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Alan Third , 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > So I guess we should do this dance around calls to maybe_quit in > regex-emacs.c: > > specpdl_ref gc_count = inhibit_garbage_collection (); > maybe_quit (); > unbind_to (gc_count, Qnil); > > Or maybe even better, do this inside probably_quit (because who knows > how many other callers of maybe_quit could be hit by this unexpected > GC)? > > Can you try this? Isn't the -[EmacsView layoutSublayersOfLayer:] the problem? AFAICT from a web search, this is an event handler method that is also called from by the framework? In the olden days, it was a serious error to call into Lisp from an event handler. All bets were off when that happened, not only related to GC. I believe that hasn't changed much. That code was introduced by Alan around this time. 1ba02d85a964e1b2c6a9735cd3decdc524e06dc1 Author: Alan Third AuthorDate: Sat Jun 12 10:25:47 2021 +0100 Commit: Alan Third CommitDate: Sat Jul 31 11:13:05 2021 +0100 Maybe Allen can say something, I've CC'd him. Or maybe we should add your fix, too? From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 06:24:21 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 10:24:21 +0000 Received: from localhost ([127.0.0.1]:55976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og1Zd-00056k-Fv for submit@debbugs.gnu.org; Wed, 05 Oct 2022 06:24:21 -0400 Received: from mail-ed1-f46.google.com ([209.85.208.46]:36764) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og1Zb-00056W-Vm for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 06:24:21 -0400 Received: by mail-ed1-f46.google.com with SMTP id e18so22323820edj.3 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 03:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=iHFXVet22DDqqk5ctk/TWMOIcLdLPPpRRYWdwOKNENo=; b=YtNQKRJdYVDSOuuzK6wvSld6/x+P9yaHfY8mB/LEjGQkrU2Wv+a/nBoC+Mn4tXKwJM DG/gi6IXlg0ckTC0zoCF4/zYqKt5uLNmqAWkFx8vfJkWEy4FFf7w9MPhW5CNNIt+grpd KAcLhmCiWcJmHUan2LtEa7cIie3pOVnTg1UPBGMakXn+m7j/TenP+OH8XE9HRsbX+1xQ mAQFDKjptrC4wsUAWUuzflbGp/0SWIWlfk1S/vQGWqoI1tSntAOJiDnU7jKhn7IEgb4S gp1XmxEr3XHC3RIktQITtz2lK8L79eMFupbACPf8k2F6rxzlDue+2Vh/dvjL+NaTGk+Y jUqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=iHFXVet22DDqqk5ctk/TWMOIcLdLPPpRRYWdwOKNENo=; b=FvvTviu6/XCwh5LdnRZx9d2gHwIZV6SlnAe4/BlGjK+i8h1JnNEml2xV3IGctoq+ym dWbO5GDfJ6O/Q2HOfBYQmmS9gYS2RnoCURt+5kdt6XhV+jGe4/LIIVXFPRNnKMdXKbEM Q12AykDmH6qmPQ1H7XGOLSneNzeXiK2CeS8+Z/QfBz5g2ZVxBdQv7Peg/nxr+EQ3tcfI BVFg1qgv7LsYISM0f8wIU2AdfLBuLZ+jcMJ5bOljp0KmmTYGnzyuZN9bwT8cPDm+uHh3 JIx3/euYSjPwzP5ZFwYLtB92mHKVIQH8y2SrBIVBsmpXuYtY9lNjjX3BrfWijhd18ZaQ yxBw== X-Gm-Message-State: ACrzQf1mvcPY5CpsJApAvz1SphlT9QQPRDZPNxMAfzdIC/JeMETnoFaY 3pKIwTULuihkYA1u6FIem/c= X-Google-Smtp-Source: AMsMyM7v9L4eu68e4J5ZPJO76tvbf7JmWh8dksteVy9+VZKsVBHScKJfCBH8Rl6NNiYgsNW4wJ7ZKw== X-Received: by 2002:aa7:c60a:0:b0:458:d707:117 with SMTP id h10-20020aa7c60a000000b00458d7070117mr16300411edq.258.1664965454143; Wed, 05 Oct 2022 03:24:14 -0700 (PDT) Received: from Mini.fritz.box (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id r2-20020a17090609c200b00782ee6b34f2sm8399559eje.183.2022.10.05.03.24.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 03:24:13 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Wed, 05 Oct 2022 12:14:04 +0200") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> Date: Wed, 05 Oct 2022 12:24:12 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Po Lu , Alan Third , 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Eli Zaretskii writes: > >> So I guess we should do this dance around calls to maybe_quit in >> regex-emacs.c: >> >> specpdl_ref gc_count =3D inhibit_garbage_collection (); >> maybe_quit (); >> unbind_to (gc_count, Qnil); >> >> Or maybe even better, do this inside probably_quit (because who knows >> how many other callers of maybe_quit could be hit by this unexpected >> GC)? >> >> Can you try this? > > Isn't the -[EmacsView layoutSublayersOfLayer:] the problem? AFAICT from > a web search, this is an event handler method that is also called from > by the framework? > > In the olden days, it was a serious error to call into Lisp from an > event handler. All bets were off when that happened, not only related > to GC. I believe that hasn't changed much. > > That code was introduced by Alan around this time. > > 1ba02d85a964e1b2c6a9735cd3decdc524e06dc1 > Author: Alan Third > AuthorDate: Sat Jun 12 10:25:47 2021 +0100 > Commit: Alan Third > CommitDate: Sat Jul 31 11:13:05 2021 +0100 > > Maybe Allen can say something, I've CC'd him. > > Or maybe we should add your fix, too? And a similar question to Po Lu because of f81065a91be5a54b78e202df6918aff443588ae1 Author: Po Lu AuthorDate: Mon May 30 16:03:11 2022 +0800 Commit: Po Lu CommitDate: Mon May 30 16:03:11 2022 +0800 which added a call to redisplay to - (NSDragOperation) draggingUpdated: (id ) sender. Is that safe here? From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 06:44:17 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 10:44:17 +0000 Received: from localhost ([127.0.0.1]:56005 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og1su-0005pY-SA for submit@debbugs.gnu.org; Wed, 05 Oct 2022 06:44:17 -0400 Received: from sonic306-20.consmr.mail.ne1.yahoo.com ([66.163.189.82]:36713) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og1ss-0005pI-36 for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 06:44:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664966647; bh=sZ/TQsX54w1zbNDSSZ2bEEZmS8QuX3ea80IthPTWqeI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=kybtFxiLvOZzKugzJdGzeJpP1qoOyoANzSFmX6ZpXI6fkXYnzSF6KmVw6fx4+KoJAICDZDFLp+sU45JowtbLeCkjiFUSqsgUdwgD+/kAAGpmGRU2d+hcASMXF7ce/ZWaHfUt7steyBSoHAAJvG/HqeCubipoQxrdVN0mxbSkVladImcq4MER7FEUWcNHslyBmijiohe42lxnN9OErAnBsHxOQVBHpyZWl1+8sBlx+wfaV5E0VxvRH25HQqncT5rkGVJ2Hb6Tc2evTFm5Ag0ZdSk658tvNqqNFkYV7P0Aksrl5ZKpIjbTuaWvQeZC9lM2qcvw+LUpF4ShA001YW4REw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664966647; bh=d9jr5E/PkHUxnUqwai6OCm0p8yr6XUOC5ZTj5QxIbUJ=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=UxApzB1ozoTTZIBBOtavTcyIwYO/cVz0qw/bcg9Zg6u9IeT4wxrPkyg49tVVxqn+gd4HOlAygefyv038y9WsPhd/qmLmCg8OZXFy63CJ5OKHAvH+D/+C3eJBVM0H2XXlOAH7AklN8Cmj+PodMT18kUs6ECna2sluZ1+igawZe+xfsUjyu9igjjUM07ineHr8pX7jEXTzWB52N8Ym1ABphq0c+iyvC+Ofg+wG/Qmo303fTR3fMxeAfXlEdYHGAzOOiRrIqpc3HhR0w6KQz6jiA2/FRnS4yI9J7iY/+V84jdwL5HepVDtr11Lvf0DNjkyNDGmD8JP2M88VF0moKVqZ5w== X-YMail-OSG: gBgpqAwVM1lZQ_.hbAzGc2g_Ksx2I99xBUUjW23lRhJVpacTojO4hbbDdhjgVSs AoMviuXwBB.Notr7egeATcGz4xW7UUITkgnzSmFLWU3PLqaWNgyBrcU1Dw0S9.V3RQqlEc.fNRbT Yyo3XZhi.gBGL4zTVlY8eXJP7EafYcSSpZOQruxa7oIoXwUixXJVplSVQ.EGXeyT7k0_Ijnk7kUp 9K2.hdhOKKC92ewuQplAGaGFyaki5btihaAEY2eDmKQn.0zEPrJL3i.o5K7_HnQK7K8bocNxW1AV 9J97SA0lcmf9ggE1vjElQuvBH_mqk6BDyBHhcECXyJgrjdYDhU6EbU_NWRwvbONl.1_tqiW0d1z7 8BpYwM3gfG0OpmwtQP2C.MYucUSOM4hc0rZTyCOmh8uAHLYXU2HZQ39wWBEIhmouwx_oEt3zUHo4 9hXX6lpAUX5dJmfGe.BvJg6HYnKdLYMbb64W6duRxZOnd2tPDKld.ed4WfU44SGmVFfxojUTSLn4 HaA2zeAqUMSU.KwPxe8VAnwLE2Cfyo3QZoH0pXnU_X8w9TTHGM2rcTLHAv3A.s4lIU6BotRr_Bz1 69qmRJEN9rkVuvPKbcTRazisW49xBej7E1G6OZGj0kMHXhnYylFQJD_TIeox6lFXx1RpUVkogBC1 PH7beUqZ6TxemJlRnqrvD3Pr8dqf5D.fhdUm0b0TIb3X4p3wzgwOa__1sX2IHg91GscSjcWRZrCn 823LDciVT5ZfYdt8DaTYsFXZlLY7RNRNiz.AIFvfULuOdl5a002MW3SwEWLG0J0Bi5.Fji6Ey7tQ hJ0Xzl8ndoAy6aoKWHp1V96h_GsI1NV7WZd49S7o0bmal8ivVxCxoPbvKK42tWrUok9SlBptgNH6 srXxjP7QpRJ8ebGMtNB0TB1qLPkurOsGWGz4imEPjo_1ocspGv5sLBjmj29FxB5xrROExUCtIe0r RqOEf9.R_diA9ge3RXmmGXDIgfWdanAnlKyYyGWgZ1AoANZ2r0WmredMdcBlz8IqNNWONTI_Kg0Z U3ZWnz10V9u1ETUE6VolONiRjdQtJIhLsINEqkkk.Gl6DMj7StJjk061_bcxNy2hTIsAMtZmJOc_ 6H0aM2DBO9_PfCQn9zne7W5PmrioUnQMU_8m1_yJ4xoktH3DBcBleYuxWINjj.xmXkUd8wpcBYy8 nUOLm1cHEP4h3JhnqMXTx9Zf3aGHap7DoxhOlPin.ak7RC7l2gM5ru8xj9YlxfDTuPsTSuEcm3dt .ZtmxsmV5JQsODpimXLNwbzzKZ0nNs5ZRH3PGl.STmiM2Ae4OlVVZv3LBEJzpuyHqqryuGLL41RL WRMmuWD2w.UOFYQ2okZaTz4r4gJzCmu5xewqzWijUZUJaXoyQULzG7lHdi5gv.EsjzsSYh0biKzI OC_rI3RuiutHb1.nPm9TQnjyWAkONMc5Fq7lG8SonNnjulBJOWAyGSps0YqcmDjhwv7uylP2Z5k0 BWJSLWADYzh9WUCppsytSnVHjFcYqd4_Yfdo9l1Kczhi1ML7uhWEDjhVUgGI7r0KvMX9C8ZgFW0R gLMjjeAn640mbk14xWEj94jzrexGcrqul9z0obLROUv6dEwzxM1e6b_wbJLzVf8KJ_gETvllE_by m6afbuZZhUcKHx.K8Oij5e2CK1ECJWC8C18NpVWXhT7E9vuKdqIq6HaTLIxIYP2faWwSiz_HUZcV POcLP3BlZ7g9XNHd52AdB6Nfl5Af_GCh4psejhOpPVztTKhG0C9phcHebf7Pcr05mvtPrlM066Tl t8j_4GZKBkczL7byNad3F.ci.z95T..le6CM_xRZEKkoqjXd3jmxgw4AM.95bWfHWZhbu9CBsaFA IJpNcoAm96bpeEPIcDTf.mxJBKSMtb.AgTsDtHrLlSlyOYrYzXqRbrksL1N.sC17dw5yXgCQ287h hJoUOJ8Zu4sB1p1aQkKCcm6ELXgvFKE5nlFKSwv1UVMVgbgAY5FWWFCXEy6wmhLsZbN9XGqLzibf IVfyHe.l_NNyyMpdLq8kPo7f1gJQQNf7z4UZ8RTd0RZp0LFi1HYa0qqxncpsT8nokbD_hP4M5NCF unUMaLa1csIQYXvWTsdqYO9TF894ql.YX6g0WPAQVRmVuejnQpefMexvXmlION3z.vZdpW4HPvRg 8w0sswK6mN51gbkcgGXWZykXxiGynVWuabWVxd3Sw7HgXwSjNlMYZLr1YD5Vm725bNOf3pdqezbM 8nFdLU3MLs_mLoAj69LeOBKRDqAquCxlerfo1lU2cxzHhNWqEbUJqc.GIyMnHhxQwywEXe1qP5cL 98w-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Oct 2022 10:44:07 +0000 Received: by hermes--production-sg3-cf9dc7f8d-vdvzk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7916e1caf1e14e465d13e22d9dc71a1e; Wed, 05 Oct 2022 10:44:02 +0000 (UTC) From: Po Lu To: Gerd =?utf-8?Q?M=C3=B6llmann?= Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> Date: Wed, 05 Oct 2022 18:43:55 +0800 In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Wed, 05 Oct 2022 12:24:12 +0200") Message-ID: <877d1ewnx0.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20702 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1729 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: >> Isn't the -[EmacsView layoutSublayersOfLayer:] the problem? AFAICT from >> a web search, this is an event handler method that is also called from >> by the framework? >> >> In the olden days, it was a serious error to call into Lisp from an >> event handler. All bets were off when that happened, not only related >> to GC. I believe that hasn't changed much. Today, event handling code calls Lisp all the time (through safe_call etc.) That happens in handle_one_xevent, ns_select, et cetera. It shouldn't affect GC at all because input is blocked for the entire duration of each GC, except for when finalizers are run after unmarked objects are sweeped. So AFAIU it has been safe ever since read_socket_hook stopped being called from a signal handler. >> That code was introduced by Alan around this time. >> >> 1ba02d85a964e1b2c6a9735cd3decdc524e06dc1 >> Author: Alan Third >> AuthorDate: Sat Jun 12 10:25:47 2021 +0100 >> Commit: Alan Third >> CommitDate: Sat Jul 31 11:13:05 2021 +0100 >> >> Maybe Allen can say something, I've CC'd him. >> >> Or maybe we should add your fix, too? > > And a similar question to Po Lu because of > > f81065a91be5a54b78e202df6918aff443588ae1 > Author: Po Lu > AuthorDate: Mon May 30 16:03:11 2022 +0800 > Commit: Po Lu > CommitDate: Mon May 30 16:03:11 2022 +0800 > > which added a call to redisplay to - (NSDragOperation) draggingUpdated: > (id ) sender. Is that safe here? It should be safe there since we use safe_call, as the only problem these days is that it isn't safe to longjmp out of an NS event handler. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 06:45:18 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 10:45:18 +0000 Received: from localhost ([127.0.0.1]:56009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og1tt-0005rp-8L for submit@debbugs.gnu.org; Wed, 05 Oct 2022 06:45:17 -0400 Received: from mail-ed1-f51.google.com ([209.85.208.51]:46007) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og1to-0005rR-I9 for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 06:45:15 -0400 Received: by mail-ed1-f51.google.com with SMTP id m3so22378401eda.12 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 03:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=svYq24ibbKNdqY71FdWte5+KfLnmi4IL0IdLC1kR43Q=; b=SOjVLp7Abkm6/n0xAqddvuVOJroUASDSd5KymXMZTORY2bNqSSijNfop72TSXTiH7a YEO0ck7XydMBmlpJ+0FwMDNHe0Vz6Y1RoaJC+JXxbUq83PpnKvOk70hun5LWNm5nJbja GYIESciQldK5YHWaDLPp2nlAHl9mT7kU5LDSV2lUG6Us0NJJyS/WgVh9UNPHGmtbUHYv eR5jfyFaT2kDc0zrCWvPxBF6PbaOQWdcN53PRyiFalyu/yOPli/OVSA4GxGvE+dk8b// rALq41cktAVakePGgYwwBPQK02kbkKuyFnuEWTBg+GdApd2xPl5cPwTu9DPSlFK9kKu1 0i0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=svYq24ibbKNdqY71FdWte5+KfLnmi4IL0IdLC1kR43Q=; b=CCiajvjq6pzX4wz3kTDxRbSelOJD9sq0RJEKl5z3lJzaY4+zmglwnOUMithHreca/b fLor6KWGevNHfUQ35Eto3m1WTZrnvUZ3gCNDrhsP9Bd0mBP5bvu7BRKZ4vcJULX2yZEa ON/C+/sz/FD+caJH3BfxiDKujcE4+tNhDx7mSnxaiBXvA6rk2UQsXHQcRkNXwp/IGFP6 dG/f6TcyFtX6BrTC45YOxH3Hgq5+0Titjilw18URkb1giknOrPatJ6FaRCxGMfFxiA0W ZkqjhR+X/I9FAbT5IXpJXT+LpDZQ5gsitN8+6sR74cRKlYrrValglwFSSDgea8BSiO3R QIvA== X-Gm-Message-State: ACrzQf2/2sKjbzE7McGKQNC+j9YYQfFrzn98jt8Qm17hOOfjJwm8Vaff gDHCa0glh46gbRduj1NUanUxRWxI+l/xog== X-Google-Smtp-Source: AMsMyM7qhSOaG0y8Mforrg0mcCM0M44lBk72MkwktmbCFmDeH00Wa6gOF3Ml2lERf94PJw6V/QLGfQ== X-Received: by 2002:a05:6402:528a:b0:454:8613:6560 with SMTP id en10-20020a056402528a00b0045486136560mr28795742edb.252.1664966706072; Wed, 05 Oct 2022 03:45:06 -0700 (PDT) Received: from Mini.fritz.box (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id n20-20020a05640204d400b00458b8d4f4d5sm3525030edw.57.2022.10.05.03.45.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 03:45:05 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Wed, 05 Oct 2022 12:24:12 +0200") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> Date: Wed, 05 Oct 2022 12:45:04 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Po Lu , Alan Third , 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Gerd M=C3=B6llmann writes: > >> Eli Zaretskii writes: >> >>> So I guess we should do this dance around calls to maybe_quit in >>> regex-emacs.c: >>> >>> specpdl_ref gc_count =3D inhibit_garbage_collection (); >>> maybe_quit (); >>> unbind_to (gc_count, Qnil); >>> >>> Or maybe even better, do this inside probably_quit (because who knows >>> how many other callers of maybe_quit could be hit by this unexpected >>> GC)? >>> >>> Can you try this? >> >> Isn't the -[EmacsView layoutSublayersOfLayer:] the problem? AFAICT from >> a web search, this is an event handler method that is also called from >> by the framework? >> >> In the olden days, it was a serious error to call into Lisp from an >> event handler. All bets were off when that happened, not only related >> to GC. I believe that hasn't changed much. >> >> That code was introduced by Alan around this time. >> >> 1ba02d85a964e1b2c6a9735cd3decdc524e06dc1 >> Author: Alan Third >> AuthorDate: Sat Jun 12 10:25:47 2021 +0100 >> Commit: Alan Third >> CommitDate: Sat Jul 31 11:13:05 2021 +0100 >> >> Maybe Allen can say something, I've CC'd him. >> >> Or maybe we should add your fix, too? > > And a similar question to Po Lu because of > > f81065a91be5a54b78e202df6918aff443588ae1 > Author: Po Lu > AuthorDate: Mon May 30 16:03:11 2022 +0800 > Commit: Po Lu > CommitDate: Mon May 30 16:03:11 2022 +0800 > > which added a call to redisplay to - (NSDragOperation) draggingUpdated: > (id ) sender. Is that safe here? And an update to the second ASAN error that I could actually reproduce by starting Emacs on my branch: =3D=3D64010=3D=3DERROR: AddressSanitizer: heap-use-after-free on address 0x= 000107130d00 at pc 0x0001002a48d8 bp 0x00016fdcaa80 sp 0x00016fdcaa78 READ of size 8 at 0x000107130d00 thread T0 #0 0x1002a48d4 in PSEUDOVECTORP lisp.h:1110 #1 0x1002a4944 in SYMBOL_WITH_POS_P lisp.h:1122 #2 0x10025a3f4 in EQ lisp.h:1342 #3 0x100280f6c in run_window_change_functions window.c:3964 #4 0x1000f1980 in redisplay_internal xdisp.c:16600 #5 0x100107cb4 in redisplay xdisp.c:16111 #6 0x10089364c in -[EmacsView layoutSublayersOfLayer:] nsterm.m:8661 #7 0x1900a9624 in CA::Layer::layout_if_needed(CA::Transaction*)+0x224 (= QuartzCore:arm64e+0x20624) #8 0x1901f661c in CA::Context::commit_transaction(CA::Transaction*, dou= ble, double*)+0x1c0 (QuartzCore:arm64e+0x16d61c) #9 0x19008b4c8 in CA::Transaction::commit()+0x2bc (QuartzCore:arm64e+0x= 24c8) #10 0x18bee1698 in __62+[CATransaction(NSCATransaction) NS_setFlushesWi= thDisplayLink]_block_invoke+0x12c (AppKit:arm64e+0x1ac698) #11 0x18c646754 in ___NSRunLoopObserverCreateWithHandler_block_invoke+0= x3c (AppKit:arm64e+0x911754) #12 0x1892101a0 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_F= UNCTION__+0x20 (CoreFoundation:arm64e+0x841a0) #13 0x18920fff0 in __CFRunLoopDoObservers+0x24c (CoreFoundation:arm64e+= 0x83ff0) #14 0x18920f524 in __CFRunLoopRun+0x300 (CoreFoundation:arm64e+0x83524) #15 0x18920ea80 in CFRunLoopRunSpecific+0x254 (CoreFoundation:arm64e+0x= 82a80) #16 0x191e4e334 in RunCurrentEventLoopInMode+0x120 (HIToolbox:arm64e+0x= 32334) #17 0x191e4dfc0 in ReceiveNextEventCommon+0x140 (HIToolbox:arm64e+0x31f= c0) #18 0x191e4de64 in _BlockUntilNextEventMatchingListInModeWithFilter+0x4= 4 (HIToolbox:arm64e+0x31e64) #19 0x18bd76518 in _DPSNextEvent+0x358 (AppKit:arm64e+0x41518) #20 0x18bd74e10 in -[NSApplication(NSEvent) _nextEventMatchingEventMask= :untilDate:inMode:dequeue:]+0x52c (AppKit:arm64e+0x3fe10) #21 0x18bd66fdc in -[NSApplication run]+0x250 (AppKit:arm64e+0x31fdc) #22 0x100870bb0 in -[EmacsApp run] nsterm.m:5799 #23 0x1008c7b0c in ns_read_socket_1 nsterm.m:4679 #24 0x1008ae530 in ns_read_socket nsterm.m:4697 #25 0x100437168 in gobble_input keyboard.c:7379 #26 0x1004389d0 in handle_async_input keyboard.c:7610 #27 0x1004389b0 in process_pending_signals keyboard.c:7624 #28 0x100438acc in unblock_input_to keyboard.c:7639 #29 0x100432cac in unblock_input keyboard.c:7658 #30 0x1005ba024 in garbage_collect alloc.c:6256 #31 0x1005b950c in maybe_garbage_collect alloc.c:6090 #32 0x10064f6a8 in maybe_gc lisp.h:5622 #33 0x10063fcfc in eval_sub eval.c:2388 #34 0x100640838 in eval_sub eval.c:2449 #35 0x10064234c in Fprogn eval.c:436 #36 0x100654eb8 in funcall_lambda eval.c:3218 #37 0x1006532c4 in funcall_general eval.c:2941 #38 0x100647fcc in Ffuncall eval.c:2979 #39 0x100651ca8 in Fapply eval.c:2650 #40 0x10063ead8 in apply1 eval.c:2866 #41 0x1006484bc in Fmacroexpand eval.c:1149 #42 0x10065394c in funcall_subr eval.c:3019 #43 0x10072e004 in exec_byte_code bytecode.c:809 #44 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 #45 0x100654994 in funcall_lambda eval.c:3138 #46 0x10065316c in funcall_general eval.c:2929 #47 0x100647fcc in Ffuncall eval.c:2979 #48 0x1006fcd80 in call2 lisp.h:3302 #49 0x1006f4ecc in readevalloop_eager_expand_eval lread.c:2151 #50 0x1006e0b0c in readevalloop lread.c:2343 #51 0x1006e236c in Feval_buffer lread.c:2416 #52 0x100653d24 in funcall_subr eval.c:3025 #53 0x10072e004 in exec_byte_code bytecode.c:809 #54 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 #55 0x100654994 in funcall_lambda eval.c:3138 #56 0x10065316c in funcall_general eval.c:2929 #57 0x100647fcc in Ffuncall eval.c:2979 #58 0x1006ddfe8 in call4 lisp.h:3317 #59 0x1006d9058 in Fload lread.c:1483 #60 0x1006e1158 in save_match_data_load lread.c:1636 #61 0x10064e9c8 in load_with_autoload_queue eval.c:2271 #62 0x10067cb40 in Frequire fns.c:3308 #63 0x100653a54 in funcall_subr eval.c:3021 #64 0x10072e004 in exec_byte_code bytecode.c:809 #65 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 #66 0x100654994 in funcall_lambda eval.c:3138 #67 0x10065316c in funcall_general eval.c:2929 #68 0x100647fcc in Ffuncall eval.c:2979 #69 0x100651ca8 in Fapply eval.c:2650 #70 0x100654414 in funcall_subr eval.c:3044 #71 0x10072e004 in exec_byte_code bytecode.c:809 #72 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 #73 0x100654994 in funcall_lambda eval.c:3138 #74 0x100650834 in apply_lambda eval.c:3088 #75 0x100641734 in eval_sub eval.c:2529 #76 0x1006f5394 in readevalloop_eager_expand_eval lread.c:2160 #77 0x1006e0b0c in readevalloop lread.c:2343 #78 0x1006e236c in Feval_buffer lread.c:2416 #79 0x100653d24 in funcall_subr eval.c:3025 #80 0x10072e004 in exec_byte_code bytecode.c:809 #81 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 #82 0x100654994 in funcall_lambda eval.c:3138 #83 0x10065316c in funcall_general eval.c:2929 #84 0x100647fcc in Ffuncall eval.c:2979 #85 0x1006ddfe8 in call4 lisp.h:3317 #86 0x1006d9058 in Fload lread.c:1483 #87 0x1006410e8 in eval_sub eval.c:2496 #88 0x10064234c in Fprogn eval.c:436 #89 0x100646c90 in Flet eval.c:1023 #90 0x1006403e0 in eval_sub eval.c:2435 #91 0x10064234c in Fprogn eval.c:436 #92 0x100654eb8 in funcall_lambda eval.c:3218 #93 0x100650834 in apply_lambda eval.c:3088 #94 0x100641c68 in eval_sub eval.c:2572 #95 0x1006f5394 in readevalloop_eager_expand_eval lread.c:2160 #96 0x1006e0b0c in readevalloop lread.c:2343 #97 0x1006e236c in Feval_buffer lread.c:2416 #98 0x100653d24 in funcall_subr eval.c:3025 #99 0x10072e004 in exec_byte_code bytecode.c:809 #100 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 #101 0x100654994 in funcall_lambda eval.c:3138 #102 0x10065316c in funcall_general eval.c:2929 #103 0x100647fcc in Ffuncall eval.c:2979 #104 0x1006ddfe8 in call4 lisp.h:3317 #105 0x1006d9058 in Fload lread.c:1483 #106 0x100653d24 in funcall_subr eval.c:3025 #107 0x10072e004 in exec_byte_code bytecode.c:809 #108 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 #109 0x100654994 in funcall_lambda eval.c:3138 #110 0x100650834 in apply_lambda eval.c:3088 #111 0x100641734 in eval_sub eval.c:2529 #112 0x10064efb0 in Feval eval.c:2345 #113 0x100451650 in top_level_2 keyboard.c:1141 #114 0x10064a318 in internal_condition_case eval.c:1471 #115 0x100451564 in top_level_1 keyboard.c:1149 #116 0x100648aa4 in internal_catch eval.c:1194 #117 0x100416f04 in command_loop keyboard.c:1109 #118 0x100416994 in recursive_edit_1 keyboard.c:719 #119 0x100417950 in Frecursive_edit keyboard.c:802 #120 0x10040fb00 in main emacs.c:2515 #121 0x101549088 in start+0x204 (dyld:arm64e+0x5088) That is redisplay during garbage_collect! The change to probably_quit didn't help. Commenting out the call to redisplay in the layout stuff did. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 06:49:14 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 10:49:14 +0000 Received: from localhost ([127.0.0.1]:56026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og1xh-00061l-Rb for submit@debbugs.gnu.org; Wed, 05 Oct 2022 06:49:14 -0400 Received: from mail-ed1-f51.google.com ([209.85.208.51]:45577) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og1xg-00061W-85 for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 06:49:12 -0400 Received: by mail-ed1-f51.google.com with SMTP id m3so22391369eda.12 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 03:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=/IBm9+NdGTqybfj6okkPtMdn8kmF/3UOdp5qHJbgDMA=; b=TK+0uZq5pQl9cQPnX1TfDOV8ICkHd8vElojgwPybwAIemQs+BlvGqothPzo0tbx9n7 y1n34BY0e42FLRiZZla8sbFgx5zX5uqf5v/Ts6wupXcxGde9+Gu6880Goi/NimXEj11Z rhZdqpHCXtpI6QFe4ZCq3pKvlQmarM1GcZ2FDiYQP+CG9Sn9bHKcCUTl/J+fQb7lke4Q Ed5/h54IvpaqQ+Q3W66In2Ynxt8lHj0PTocrcdSsD2pV+hw1rMgZTrVt6/qavpjut+/3 /gySUGSGVMD66cdmqh/dOvdypcTSOM0PvxwGrwnYx57z3svr2vhHzV57TrRh86gvRYKY Z9bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=/IBm9+NdGTqybfj6okkPtMdn8kmF/3UOdp5qHJbgDMA=; b=FkfZKiTEvMQmSewvivBCv6GdM46dxyvmoekZKxGrTx/IltJreAPX+h3Nb9TlkWyUY6 Dh0XuntIxWLqJ0/w/Syvaw5ZJSfgcaHef/KqfToRTQrvzqn18aUZWxc1lpJIrXPj76ow NkyoiK984ukGul7lVy3nMx9ghfOjKolr5Pf94x0a3KqXbCpgWeDjg1R2oskgF4+6ZhHP gNnTCllPYGN2Cv9k57QaBmojDYEAEgJmveEMUSFamJOdTXQITkTyP6LFrRZIz0PllZJS nziLu5drTjDt3T+It25GnvZah+PY9xjDa2uDY3g7l9r+u877p00Ay9P/fxI0ngpEOoWd fDhg== X-Gm-Message-State: ACrzQf1BR0NZPe7RvYmqkh3Vz98Yv4vwgSOhNCgl061O7ulIPF+22R1N i2K1tNyqlJcTivWMtqua0sc= X-Google-Smtp-Source: AMsMyM6EYax2g3or8wd0pldZfZnZ1h99hCrii3365t0cTAtrYe1LEZsVrd6IpJLdXXwU+bIQUn2okQ== X-Received: by 2002:a50:bb68:0:b0:458:abbd:faf9 with SMTP id y95-20020a50bb68000000b00458abbdfaf9mr19111584ede.177.1664966946732; Wed, 05 Oct 2022 03:49:06 -0700 (PDT) Received: from Mini.fritz.box (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id 18-20020a170906211200b0077a8fa8ba55sm8461726ejt.210.2022.10.05.03.49.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 03:49:06 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Po Lu Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <877d1ewnx0.fsf@yahoo.com> (Po Lu's message of "Wed, 05 Oct 2022 18:43:55 +0800") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <877d1ewnx0.fsf@yahoo.com> Date: Wed, 05 Oct 2022 12:49:05 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: > Gerd M=C3=B6llmann writes: > >>> Isn't the -[EmacsView layoutSublayersOfLayer:] the problem? AFAICT from >>> a web search, this is an event handler method that is also called from >>> by the framework? >>> >>> In the olden days, it was a serious error to call into Lisp from an >>> event handler. All bets were off when that happened, not only related >>> to GC. I believe that hasn't changed much. > > Today, event handling code calls Lisp all the time (through safe_call > etc.) That happens in handle_one_xevent, ns_select, et cetera. > > It shouldn't affect GC at all because input is blocked for the entire > duration of each GC, except for when finalizers are run after unmarked > objects are sweeped. > > So AFAIU it has been safe ever since read_socket_hook stopped being > called from a signal handler. > >>> That code was introduced by Alan around this time. >>> >>> 1ba02d85a964e1b2c6a9735cd3decdc524e06dc1 >>> Author: Alan Third >>> AuthorDate: Sat Jun 12 10:25:47 2021 +0100 >>> Commit: Alan Third >>> CommitDate: Sat Jul 31 11:13:05 2021 +0100 >>> >>> Maybe Allen can say something, I've CC'd him. >>> >>> Or maybe we should add your fix, too? >> >> And a similar question to Po Lu because of >> >> f81065a91be5a54b78e202df6918aff443588ae1 >> Author: Po Lu >> AuthorDate: Mon May 30 16:03:11 2022 +0800 >> Commit: Po Lu >> CommitDate: Mon May 30 16:03:11 2022 +0800 >> >> which added a call to redisplay to - (NSDragOperation) draggingUpdated: >> (id ) sender. Is that safe here? > > It should be safe there since we use safe_call, as the only problem > these days is that it isn't safe to longjmp out of an NS event handler. Ok, I can't say much to this. But please look at the my latest post. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 07:10:14 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 11:10:14 +0000 Received: from localhost ([127.0.0.1]:56052 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2I2-0006fC-L8 for submit@debbugs.gnu.org; Wed, 05 Oct 2022 07:10:14 -0400 Received: from mail-ed1-f54.google.com ([209.85.208.54]:37719) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2Hz-0006eq-4c for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 07:10:12 -0400 Received: by mail-ed1-f54.google.com with SMTP id w10so9589197edd.4 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 04:10:11 -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=pFKyRvxNzpDDEzRBsReciFXdpNod3o/6NZrRH7FctMo=; b=K4lmYaNjQSI3NpOrX9RYY3nwbNwCWlOS66Idc+h+IbPvdIsxPIS3oAY6Q9qMyJv+et W2xIJI+RLqg8j5kt4RW0q7jcWSSnRvtmX86CP2CoTgBZ8JW1DOOho01oGC/AXlgRKOcP cFVY2mRmxLMKlfFs1MiliMjAp7RUs8qBwteiI8Hp8XR2u1AKOfL63RrP6toHsuZo+47w SZivCkhyeZit9yCi6nKGz2LEP4Dm781DjaizUG7mW/ZA9CY2oNhOEdp0yty/Wg+kkeaw kVt40WU9NjMeCXy7vfmItYEC0j1pcfoloNabWw2sY4kqglyV6+JzlalADjxfHEnFutpD cJwQ== 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=pFKyRvxNzpDDEzRBsReciFXdpNod3o/6NZrRH7FctMo=; b=sxVQpjp61h9rxX5WeGG5zOdToFLG/G4yPAbYsEgz1d9lVF1SPpwQcD9pTCfUb1lBaF V+zXkciTc1PUO4vbbg18eEV7UIfD7hKrqZwakATazmItn1BaPpcz1SAmk5Ilxxnc/IvT 65WV7SV1FmxC+4GWHQwJ3jmdMe9d8OMRWqtolWjCGGjr5mkkQ6EDwXaGlztDwEGRxu+B Uou/thU5iuE2HHc6qfxW4d4yXbquhng3/rJd7HIKkdNrZ2lxfSQUdKHCsPsugXRp5e5b 1Lrncn9hlBnswO1mcMQQagYaXSJ9L1d5f7c5ERMWh5asJyF/U/QQPUV1yF+9e8ujkCjr 0Rug== X-Gm-Message-State: ACrzQf3mga+9XTn8CSejvTu88LLXha7bZA4O0qG5uqJN/Q0ldMxD6FOm M5j2LRhgCdte+61+qd150X8= X-Google-Smtp-Source: AMsMyM7lGJ2NMfpgd7J6c1oAtDR7ZlWQ3077gyPXAxV1gqLMNbcYauE8oVlyXCJQxY44xmELxw+tYQ== X-Received: by 2002:a05:6402:1e8d:b0:454:79a9:201f with SMTP id f13-20020a0564021e8d00b0045479a9201fmr28512713edf.176.1664968205217; Wed, 05 Oct 2022 04:10:05 -0700 (PDT) Received: from Mini.fritz.box (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id r2-20020a17090609c200b00730b3bdd8d7sm8573145eje.179.2022.10.05.04.10.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 04:10:04 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Po Lu Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Wed, 05 Oct 2022 12:49:05 +0200") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <877d1ewnx0.fsf@yahoo.com> Date: Wed, 05 Oct 2022 13:10:03 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Can somone please help me understand how this works? Let's say we are in memq called for list L. Fmemq uses FOR_EACH_TAIL, which can call maybe_quit, which executes arbitrary Lisp, which can modify L. And probably similarly in another 100 places. I don't get it. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 07:10:31 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 11:10:31 +0000 Received: from localhost ([127.0.0.1]:56056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2II-0006fn-TY for submit@debbugs.gnu.org; Wed, 05 Oct 2022 07:10:31 -0400 Received: from sonic303-21.consmr.mail.ne1.yahoo.com ([66.163.188.147]:36939) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2IG-0006fV-2a for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 07:10:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664968222; bh=PZGbv0Tpg9w+p6TFZ1eiZ5dxqfKbdcJXibFU+E5W/XY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=CBrRdYDmMCqU8IjvF33W3QE05bm7R10zxZEphs2NfdMxgaPwnLubgbpHrgt4grvHfafrB3B/DCmKdHobXDI5IuGqI95ShIHV119jqOL0sXbobaZKfL85sjY7BO/Hsitc2OdVMkNWB7enCo6HJzC/WBl1IqNSlMST3ZYYSYuhn83O39LdlC5Gsl28YFufe2aBRCsWgGjPjUylS79VSrt0eDsAlEUgmjm/oMTP1cggVxOdhOF52WJm8/djlrPn1zsY6Pl8jAr8HU6KsUBI5It+impzemm5bozWpTxvxOoYFgraFlcG8pk753UtMpWwp22EMrfo0Go0Bbx11rb2Awmgeg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664968222; bh=mXa0rAnai+yOVfoI9VE/F09K6wmzjZyAQjSDjiLdvWP=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=YkkF+mkiVgcx0MeuLoCXZHcRpfSI9cgBV2mXq6xN7hpp/bb63punoNSEwwr/On6LlZ7HXZvtaQOfnjyZ8VDxzzbMo5if++Ys1IIm3CD1nyK1xutR6GBPLK+lxsMYErptETyoaW01xawEQwOBZDaZNs0xXlY7kmS60mZ9Pkyn9WuKIb3WNBRuJRNNO2LhEW3HxzimFDDh1E985U1jiK0vVLDwBVPel4nVXkuT9cA3I/73aPH4RtRxI+s0C3ep7CAtPsjHOuYIa4fcm6zeLcwDooDsQRS345SHKyikLspT3QwybXifkbwuddWHAnDRUdobimlTb523856bfWIPVykg7g== X-YMail-OSG: 3TXPQwIVM1nV8Z037lx4WO4VJcXQLeOJwbzjfHV3vZi7lmspGJScmNm9LlZ9RO2 rfdk7HcmeUDdmjcd_wu6DZawyZHsfvKzI57MF4zuexHBLI13idLEeWp1DzeMDpNGz.biIKeRk1bd uWK5W8NHVE8cp7pvdWHg6ouJTXkpjNDakRLIgFtU2bIwILTdgaPtojp4CYvRDhgNU8hn6FVe0EgL nlEYVK2qih4NcisUR15izlfdT1v5OS9p7MRQvK6HHU2gtYFeLh2LSjQUENTAIPHmapqDXlIKqthO RlbL5craBFZiPePUE5kIi8Y6O1tK5YxwjIKB1mxYd0vNDpqjc6IyFR.70o3JT243cGjSK3SkYsAw IpvFWw4TxUYufTBDcIucKcgNLk1I6zV2gX4aZ8bv.D2lNN5tTuskhUI2Ivplrt1bKS4yj.uSYFq1 Y5KvhHrP6m_KkqW.QX31x_pr.uitspR8OrlnsLV5xlyd9fM85BsJB6pNGnzgIKwoPNxwfr0qgIGt EU2.Oc2pPNL2tRsdX0b7Nl3_uu5jcuUp55X8rqWLaFahQetHAIXPFUp4DfAOmHWD7aH8uWZJkGCf 5p0pb9cYzG5BMV4mfsuqxhZ3Y4TBv.an7iJ5swOCuWqsEB50lFObKv6yB_FZIvn1kfINV5mPHs0I 3Y59tBAC8ZdWIzhJ70mdk1emYA5f4Yf7ughEQZC70mZc_5HmemB8peF0Y1d32cbT7RjmzoxRIVLM zRjQKscT2aY7cl001NFGQAEKCV2eyYDpFu.oMMem92URB9bphHWhQq_Q3GUMPV4mjmdapEOKB8rq pvsljjvrhgz29R5QwEc08tMnK8bbn3zCtwzq_AToKfB019FI_AdVARYVpkfdqO.a2W4Z0zofKwUN K_unyz3j05pWi30qQE.vCwZui4EbCjwiQ6mZC7WorSMoomtxqNBkJXRjFvfYXEjNsTXN1dmT9rSj LyDu9EB9EozXybFoctmIEtv3glvOM4aFoUbxQtw7trWYyOmZ20LtQpo0NOBt9MZJYAk894AzPCE3 8gjZcw3aSymb9g.JuXUbz3ZLykRTr6Ab_zBTwaJYPK.XS.bVIx7zXiXWN_n3Q5Jp760GxQUTnBzE nOw29V5DbmLJrtfss6_7bcAPmVpNWuHQlM_CNul3JCmlojj7ZInxZSE4fPxmg5ltAJapkag7nldZ 7QsJKBd4.ScoBzpFEWrOwkg2zTQA3O6fO_7LQIySLGn75Xyo0q1_sg_uEwRXEkFJMu8CSIGITsZg 73Grqz46K7TBexUeSEWRI3wEAL.paB3kv44dZ.VWyKSB8Wqo6EQj_nUXYesA87shDi6NMIAzvL2_ d5jBmbgr83T6OD.Z39ZsiXM8HvEz.k7AwLeAJ8qZt3Awf9q3a7bSZvth2oCGuOuFqpitB_yIM3sB gWYszh84ww4C8uoDI4ZzsLA6mIzqNTj3Lj_Z7gH8OIfjSUv_b_2tei08XXk7KfAiJ8McErRUEbVj yXgAiblGjiOzIyLUHkP7iSWtBtvQiUxWoTpZEypTqKYSqCLhuvkFOczLrGXmCYDfbP1Cwm7ZQzBO bW7bSMlNajfHbwxasJlxyQ5CNIozP0HFhBGF8moHTacXX4dWiWo_wbtbsPYMlJJSuYcuQWijiwKH 1U5mBQ9X860mi4z6DUW1uz1sbLCNBa2Io2cglDSxCasDNv5mzZTlB_U6vWuGDYE_yVvw6p8ezQiW rSaGxscUx4yMs_B3QFAd0MclqozmFzNOWzbsiyW5X1aUjSKd4XXBzobQDGnB_bUadNA6NcNHbyAM deWzw5KxLgGwkYuPxKwnO8lnKgh7Mwf_7m31REu6pdjrJqDZFHxKFXHi6tmYB2BVlbVLnlgScHOf 8zUhB.xz3u7z3qcCfjRzoZ1Hjq6eUL.kHQTn.RS5JUSDZ5pF_ifBk2CG5u.b2n1t6E4K5kzsrnGf 8ycga4zVu0gCPmnaWut3jzrkpag5dojNsa9BoFm0fmD.rRiTKeU13X.lbkbQjYjBEpvZDUdq35er pxK2opKmfIZG3ngZ4HrV900OW._NU5KFnpqyAcEIrXORdAqSX1r1_AJesCWrJ4ljCarm0JMZiK12 p6k3PUSfA7MJsmH.fbHIBHNegsU.VqI4TjfjNx6lv_FlL.BAi91MRPStREGqQcCoeJGOU1bdv6ig 0izBY7I4LpTDv20l3DaUDQxEbpkJH4dlhVDJN96pzJ3rwBagNWjAk8Ra5L3oiIQiAHpzcDilEXwE AhzhMAR.VsCiUFr.cAqx39LGJ_iNp.ILC49YYjVRVD6C8wzEhOrIeixFKxP_jvo4nkPIXDKMlYsM I X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Oct 2022 11:10:22 +0000 Received: by hermes--production-sg3-cf9dc7f8d-4879b (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c7b3293fabd89508ec75b032532be11f; Wed, 05 Oct 2022 11:10:17 +0000 (UTC) From: Po Lu To: Gerd =?utf-8?Q?M=C3=B6llmann?= Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> Date: Wed, 05 Oct 2022 19:10:02 +0800 In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Wed, 05 Oct 2022 12:45:04 +0200") Message-ID: <87y1tuv851.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20702 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 8311 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > And an update to the second ASAN error that I could actually reproduce > by starting Emacs on my branch: > > =3D=3D64010=3D=3DERROR: AddressSanitizer: heap-use-after-free on address = 0x000107130d00 at pc 0x0001002a48d8 bp 0x00016fdcaa80 sp 0x00016fdcaa78 > READ of size 8 at 0x000107130d00 thread T0 > #0 0x1002a48d4 in PSEUDOVECTORP lisp.h:1110 > #1 0x1002a4944 in SYMBOL_WITH_POS_P lisp.h:1122 > #2 0x10025a3f4 in EQ lisp.h:1342 > #3 0x100280f6c in run_window_change_functions window.c:3964 > #4 0x1000f1980 in redisplay_internal xdisp.c:16600 > #5 0x100107cb4 in redisplay xdisp.c:16111 > #6 0x10089364c in -[EmacsView layoutSublayersOfLayer:] nsterm.m:8661 > #7 0x1900a9624 in CA::Layer::layout_if_needed(CA::Transaction*)+0x224= (QuartzCore:arm64e+0x20624) > #8 0x1901f661c in CA::Context::commit_transaction(CA::Transaction*, d= ouble, double*)+0x1c0 (QuartzCore:arm64e+0x16d61c) > #9 0x19008b4c8 in CA::Transaction::commit()+0x2bc (QuartzCore:arm64e+= 0x24c8) > #10 0x18bee1698 in __62+[CATransaction(NSCATransaction) NS_setFlushes= WithDisplayLink]_block_invoke+0x12c (AppKit:arm64e+0x1ac698) > #11 0x18c646754 in ___NSRunLoopObserverCreateWithHandler_block_invoke= +0x3c (AppKit:arm64e+0x911754) > #12 0x1892101a0 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK= _FUNCTION__+0x20 (CoreFoundation:arm64e+0x841a0) > #13 0x18920fff0 in __CFRunLoopDoObservers+0x24c (CoreFoundation:arm64= e+0x83ff0) > #14 0x18920f524 in __CFRunLoopRun+0x300 (CoreFoundation:arm64e+0x8352= 4) > #15 0x18920ea80 in CFRunLoopRunSpecific+0x254 (CoreFoundation:arm64e+= 0x82a80) > #16 0x191e4e334 in RunCurrentEventLoopInMode+0x120 (HIToolbox:arm64e+= 0x32334) > #17 0x191e4dfc0 in ReceiveNextEventCommon+0x140 (HIToolbox:arm64e+0x3= 1fc0) > #18 0x191e4de64 in _BlockUntilNextEventMatchingListInModeWithFilter+0= x44 (HIToolbox:arm64e+0x31e64) > #19 0x18bd76518 in _DPSNextEvent+0x358 (AppKit:arm64e+0x41518) > #20 0x18bd74e10 in -[NSApplication(NSEvent) _nextEventMatchingEventMa= sk:untilDate:inMode:dequeue:]+0x52c (AppKit:arm64e+0x3fe10) > #21 0x18bd66fdc in -[NSApplication run]+0x250 (AppKit:arm64e+0x31fdc) > #22 0x100870bb0 in -[EmacsApp run] nsterm.m:5799 > #23 0x1008c7b0c in ns_read_socket_1 nsterm.m:4679 > #24 0x1008ae530 in ns_read_socket nsterm.m:4697 > #25 0x100437168 in gobble_input keyboard.c:7379 > #26 0x1004389d0 in handle_async_input keyboard.c:7610 > #27 0x1004389b0 in process_pending_signals keyboard.c:7624 > #28 0x100438acc in unblock_input_to keyboard.c:7639 > #29 0x100432cac in unblock_input keyboard.c:7658 > #30 0x1005ba024 in garbage_collect alloc.c:6256 > #31 0x1005b950c in maybe_garbage_collect alloc.c:6090 > #32 0x10064f6a8 in maybe_gc lisp.h:5622 > #33 0x10063fcfc in eval_sub eval.c:2388 > #34 0x100640838 in eval_sub eval.c:2449 > #35 0x10064234c in Fprogn eval.c:436 > #36 0x100654eb8 in funcall_lambda eval.c:3218 > #37 0x1006532c4 in funcall_general eval.c:2941 > #38 0x100647fcc in Ffuncall eval.c:2979 > #39 0x100651ca8 in Fapply eval.c:2650 > #40 0x10063ead8 in apply1 eval.c:2866 > #41 0x1006484bc in Fmacroexpand eval.c:1149 > #42 0x10065394c in funcall_subr eval.c:3019 > #43 0x10072e004 in exec_byte_code bytecode.c:809 > #44 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 > #45 0x100654994 in funcall_lambda eval.c:3138 > #46 0x10065316c in funcall_general eval.c:2929 > #47 0x100647fcc in Ffuncall eval.c:2979 > #48 0x1006fcd80 in call2 lisp.h:3302 > #49 0x1006f4ecc in readevalloop_eager_expand_eval lread.c:2151 > #50 0x1006e0b0c in readevalloop lread.c:2343 > #51 0x1006e236c in Feval_buffer lread.c:2416 > #52 0x100653d24 in funcall_subr eval.c:3025 > #53 0x10072e004 in exec_byte_code bytecode.c:809 > #54 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 > #55 0x100654994 in funcall_lambda eval.c:3138 > #56 0x10065316c in funcall_general eval.c:2929 > #57 0x100647fcc in Ffuncall eval.c:2979 > #58 0x1006ddfe8 in call4 lisp.h:3317 > #59 0x1006d9058 in Fload lread.c:1483 > #60 0x1006e1158 in save_match_data_load lread.c:1636 > #61 0x10064e9c8 in load_with_autoload_queue eval.c:2271 > #62 0x10067cb40 in Frequire fns.c:3308 > #63 0x100653a54 in funcall_subr eval.c:3021 > #64 0x10072e004 in exec_byte_code bytecode.c:809 > #65 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 > #66 0x100654994 in funcall_lambda eval.c:3138 > #67 0x10065316c in funcall_general eval.c:2929 > #68 0x100647fcc in Ffuncall eval.c:2979 > #69 0x100651ca8 in Fapply eval.c:2650 > #70 0x100654414 in funcall_subr eval.c:3044 > #71 0x10072e004 in exec_byte_code bytecode.c:809 > #72 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 > #73 0x100654994 in funcall_lambda eval.c:3138 > #74 0x100650834 in apply_lambda eval.c:3088 > #75 0x100641734 in eval_sub eval.c:2529 > #76 0x1006f5394 in readevalloop_eager_expand_eval lread.c:2160 > #77 0x1006e0b0c in readevalloop lread.c:2343 > #78 0x1006e236c in Feval_buffer lread.c:2416 > #79 0x100653d24 in funcall_subr eval.c:3025 > #80 0x10072e004 in exec_byte_code bytecode.c:809 > #81 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 > #82 0x100654994 in funcall_lambda eval.c:3138 > #83 0x10065316c in funcall_general eval.c:2929 > #84 0x100647fcc in Ffuncall eval.c:2979 > #85 0x1006ddfe8 in call4 lisp.h:3317 > #86 0x1006d9058 in Fload lread.c:1483 > #87 0x1006410e8 in eval_sub eval.c:2496 > #88 0x10064234c in Fprogn eval.c:436 > #89 0x100646c90 in Flet eval.c:1023 > #90 0x1006403e0 in eval_sub eval.c:2435 > #91 0x10064234c in Fprogn eval.c:436 > #92 0x100654eb8 in funcall_lambda eval.c:3218 > #93 0x100650834 in apply_lambda eval.c:3088 > #94 0x100641c68 in eval_sub eval.c:2572 > #95 0x1006f5394 in readevalloop_eager_expand_eval lread.c:2160 > #96 0x1006e0b0c in readevalloop lread.c:2343 > #97 0x1006e236c in Feval_buffer lread.c:2416 > #98 0x100653d24 in funcall_subr eval.c:3025 > #99 0x10072e004 in exec_byte_code bytecode.c:809 > #100 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 > #101 0x100654994 in funcall_lambda eval.c:3138 > #102 0x10065316c in funcall_general eval.c:2929 > #103 0x100647fcc in Ffuncall eval.c:2979 > #104 0x1006ddfe8 in call4 lisp.h:3317 > #105 0x1006d9058 in Fload lread.c:1483 > #106 0x100653d24 in funcall_subr eval.c:3025 > #107 0x10072e004 in exec_byte_code bytecode.c:809 > #108 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 > #109 0x100654994 in funcall_lambda eval.c:3138 > #110 0x100650834 in apply_lambda eval.c:3088 > #111 0x100641734 in eval_sub eval.c:2529 > #112 0x10064efb0 in Feval eval.c:2345 > #113 0x100451650 in top_level_2 keyboard.c:1141 > #114 0x10064a318 in internal_condition_case eval.c:1471 > #115 0x100451564 in top_level_1 keyboard.c:1149 > #116 0x100648aa4 in internal_catch eval.c:1194 > #117 0x100416f04 in command_loop keyboard.c:1109 > #118 0x100416994 in recursive_edit_1 keyboard.c:719 > #119 0x100417950 in Frecursive_edit keyboard.c:802 > #120 0x10040fb00 in main emacs.c:2515 > #121 0x101549088 in start+0x204 (dyld:arm64e+0x5088) > > That is redisplay during garbage_collect! Yes, but that is redisplay after the main part of garbage_collect is over: after that unblock_input, we even run finalizers (Lisp code) straight from garbage_collect. I'm going to guess that window_sub_list is returning a window that was not marked during GC. It's a problem that also exists with my incremental garbage collector. Does this help? diff --git a/src/alloc.c b/src/alloc.c index 419c5e558b..522925d248 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -6634,6 +6634,9 @@ mark_window (struct Lisp_Vector *ptr) mark_glyph_matrix (w->desired_matrix); } =20 + if (w->next) + mark_window (w->next); + /* Filter out killed buffers from both buffer lists in attempt to help GC to reclaim killed buffers faster. We can do it elsewhere for live windows, but this is the From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 07:15:40 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 11:15:40 +0000 Received: from localhost ([127.0.0.1]:56077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2NH-0006qR-VQ for submit@debbugs.gnu.org; Wed, 05 Oct 2022 07:15:40 -0400 Received: from sonic303-21.consmr.mail.ne1.yahoo.com ([66.163.188.147]:39040) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2NH-0006qA-2F for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 07:15:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664968532; bh=G+vhWTOIGvwGUNFqHSYIPOIWJUVkqBvshrZ904BKNQY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=Qgc7l0rFO4JY9jsJd3pOLhCOBsYhKTwgNnWs+Huv9XjmDHCGDJW+4E09ewms4DomhdZgTr2AyFw7wLHXQczl2QAFmFFFMwJMpnkMqfNufyAkAEEBuZmGCLAh1Zxl7hr3ENNW63PgR/8un0fkdJnFWdfu8SKH4ZX9IGkEa00HxF8JnvKW7plmzePOUxsCadJVugojuYoXznPG5zmeAsgmloN7GUJ06qbMANBilD5fbCnlXatRmsKWfLlLrBw7rVmuKOxEkAWZNlc8N5EPZ2DKS6M9EbbfbCL5EsCtxfRcA2m7iJJSoy5YwZZWluVMjoq+HS79aM+33e0ebr98u1iiOA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664968532; bh=uVwsXQ9aUJrziKaLbrOH/pVZHtAOR3tR/IKG+GD2J7j=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=KvplND5Ksb0+9kvpXMTCvcPDQawCm3T8lxrOabV7+qMXxFxMbHdTVjKrkUiYjO8K+kiWRH3TNV+Zz2wkp8uEVson+n3N172c22mBrKToznJ57dtU4nq3a4BndeV1wP1aSGVmO+Vqb8ieKP+a+8Mh2XWSyKi3LqT2uo+p4FXeHtIdJ2o3d7FiZoBbOVDNS5zAaAkF7cx2vBXgoa9I2AajDPLGagvGeZvCm7LU3wDK2sJIkmtvSuvXeuvmv49RoAVI54o3Vj14AkTZaen+NO8uXtm7XZFk50FgGmDiuv+ht0dai4E3mOiHslsucqgs2AgPGN98qjP7tTjsgpvOMOtXfQ== X-YMail-OSG: 6r13atsVM1l_QQgR5UOMUoowfq1aMbrUDz4Nwaum7aZL9Y3RI5Q3fSlOuLCrICb 45CgrFy_jO7USepY3x5yoY0r6DYtjRCdNaTCB7s8GHXwYWeVGBbQNwYOrIIxkiftnSv3whvkVHrB .sviByAsGX.CRryi8RvFOwoavtwm_j.EcMMgFQ6CGZrd.mEQJGvDeTR3lglNDe.pLjihpDHjAIKX jjTX97vgyCRYKLwaFV1w604keWfW6rypJDWH4hd9zCrn09g_YiA4l4OhC_7LcgQf0mgRjPtRiH5O 2EJpyVF2cd_MWK.qaLfE5LGZIdmq8r0QSM0lQCW.Cn3PrlASF7zZVa71ka_ZD4x3S7OI1bp0tZN4 7a_1EJfCBxIbjscaFdekufkHOMGk2bvT0WhHGGzI5Yy9XPcSzL83xClQDxnklMkIYdihr3DvRuFI X8Jm_M3oeXIRIz.GrwEhTsBbtxFOVCm1.aHLHG.mFe6bPli0t_ED43gi2vWj32Jb0NpXFCZN6jBp Y4TfZ59mIEH64GJE3qWIWxiyq9rGneZN3KADmwOU1CNJ9yiz8caygd5I1wZMAURO8qugP740ZWDl 13ngVM5vU6sV6ecgj0KIl_Dk4_ByzOp6Q9oQp3ElheJqmwzgvS.v.KKS.D9EuqKPLDK5LqmBSfQO uRAbHiwFl0XzGyoh15RYWkbIk7kKWrpvo9b6BzWfcLHRfCGUIvuEShaFEFYkPvnpEWuG8RXiS52K bemAtMtJtR_ozHnkphVKNNcwZo8lUznwOFhMihinO.b9MABCcGYg1d.mSJZRNFg2YVR3fMib8C5d PauaedoYHXikHAFiq5tRDA_BV3RToCebwdY5TUC7MTEIzbMop5d3AIPNXAnl1UlewlY59UOLAtwU IfTpcOZXjDQNaN5fpXFPijSTKOQeIwIbfsBeNfEqrx4Y._xrwaPIM_eGqSqcMj7RGbjNj37T3SvL ll5ftVmy9ckkg3X7tWkDrVzZMh10IfWRz1pGzsS0P4rtPlNmLSQrEbf8UArg6roftXwIaDGts3J_ l0nr11WBGZhnXWKnyBIdq_ZoPUgw5QeopcggZ3oHpDqgiYu3zc.HVVnqnnIPpRWdCoo4fZ6XyhAX 0Kc_6iQJv4W5VgsHW9Czuj4hz7Z6LMB1EGKVcmlRB5PL72j2UqW6bF7JC3lE82Tt4nNJ64w2F9Ei C7wX2ayLMhp6ReyldtnZfCnkLvXa3YPoqyLYBL9qrsreUBwi2wU1oa9KxlK7bMG44hycl27vSBUb QoWLGYc09D6icDF0SBTe0OQhwG8Pk1DTEcLFv3gKeOv5.Uxn0HiaPsedbjVdecxass8Euo1fHVmb E6PYwPEfQnZx19lroMpSjc3D2rSGfIa8gbijedztO1XwmiYjTKc4UydAd2hh.Nk3xRvS4nOQQgFx QHSj9.hQKJ3rKj96M2LaOh11nHaV_QHGZK6z.Y9OGCeNxIV5WIdmcTx7rG5CyeveyOaLzIpzdNVJ QPCDJ9dBSKPvOV2EOMwDUOA1VG2ew_ZzSuVZEvBQot1F5OCCLTK7sOPBsPwAlDcQZCqGo64eQLJj 4uP5kIrTJhRrPcmPWUxYasorPNDQzIEOKNV6mzi0WBRZcehyrjh7yIFKrub7QFYdgExOuVE_ARME 5X0IUtrGzksGvkXgmD59i3Z38kwfLWLplxkqT4SbL381LyzojA_82jza52pYfyYwuoVcx9v53zDC DSj238EcmzF9yiXJ43DBFeuW3r62wYculodcvPSEWYJgqMGFeQkr_xjDVZi_JvKCsR7vEEZMuPO4 Z5G15Q4k8XbJKPfgjCMGLmmWi9c2rgSDBmQaAYxLurQq_LVuJeXA4kclqw34mbHKkxdlCvuzq3n_ Iibk1L8T.IoLE3UMoCB3WobABcVQGWQ1ixpVxzl5cyyuuKTAZEjV888zw45mc3dJsEBOH64ENat8 d1xMIeIT4WW5SQY9rT.EDGVr_KxkM1dQXcph_zxEd53zKDoNBs.urVQFWu8CrbzJvm_tRnrkxjnq zU1DHtcnNENr.aiJ1OwvQtJ6NXs5MV3stkxHa623_0drWcnnqkzeECcCntKsWYqy97bZWMYV.Dlw g.X6TaBsFXUKv5UqfT1wXBG0wUlbtHIQ.AU8IomyhKQdupQN3bUAXnhV5pIva53Ur0paVwHE1A40 cxc5zsVGv1GpYpYvWdxeKcPXA.SP5pqiwW4_rgxQ3M9oAHXmamsFAVlIU0o9JOIDqVZ5.QA.vueX .nntwgGlEOCSrAu.Q0yOQdCkzRkBWQmgIeclLgEm0G7goWWOSuaGQ5tNcIUeVpERarkQyWwtv0YK f6ao- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Oct 2022 11:15:32 +0000 Received: by hermes--production-sg3-cf9dc7f8d-pxk2f (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fd0a0b8d1cf950ad5fb02ebe93ea7f42; Wed, 05 Oct 2022 11:15:29 +0000 (UTC) From: Po Lu To: Gerd =?utf-8?Q?M=C3=B6llmann?= Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <877d1ewnx0.fsf@yahoo.com> Date: Wed, 05 Oct 2022 19:15:22 +0800 In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Wed, 05 Oct 2022 13:10:03 +0200") Message-ID: <87tu4iv7w5.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20702 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 435 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Can somone please help me understand how this works? > > Let's say we are in memq called for list L. Fmemq uses FOR_EACH_TAIL, > which can call maybe_quit, which executes arbitrary Lisp, which can > modify L. And probably similarly in another 100 places. > > I don't get it. AFAIU if it is particularly dangerous to modify L there, then input should be blocked around Fmemq. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 07:15:59 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 11:15:59 +0000 Received: from localhost ([127.0.0.1]:56080 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2Nb-0006r4-7O for submit@debbugs.gnu.org; Wed, 05 Oct 2022 07:15:59 -0400 Received: from mail-ed1-f42.google.com ([209.85.208.42]:40872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2NZ-0006qo-6F for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 07:15:57 -0400 Received: by mail-ed1-f42.google.com with SMTP id x59so12522067ede.7 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 04:15:57 -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=KXEy294q45Emy6bD3RWxzbQPERr4doiAkzwHoEgzeSA=; b=Jiqx1/GDU8+YIzCr5+ikh1w1Thdd2yBLPI2h3DEyucksvnQyPu8L8my704FvdKKtWu 9SZ6CSCWaLoiXIbQbZFxcbMtsdz3x98qArBuHv34i5W8GpISjxXP62c+AHWD3NIt9+Vw VNxD58ObWo2A7K6h7djiiB4c6+MgZCWEix757cC+ZWitjTrFPu6wN/M9acMwogVM35im dvNrb2xe+kwHEipEkhebouO3hVpJ/yOfTTX7TW9RDdg0+OOvZ/3q0oFitBud+T9yJYYR TLMWEWUwgB1D/p3ZXP0wlCiAUlb888vbQG8kfpsvZZ3JnUJBVDlTD/lth2stPRNqxSn9 pMzQ== 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=KXEy294q45Emy6bD3RWxzbQPERr4doiAkzwHoEgzeSA=; b=qC0f9pczPbpU6bBcoTJ08y5Ic6mf+hhEoxnblK7gXRwNagYu8HSMdUVlr1nwFvXK7Q AOcX2kSxq0fci6aHc7Jn1O78CMvRq8D/hwc7IdpnD041ynGOXNglIy5GNkDrUEfqJAf6 qLSHvtLmiCGXpBKIgKdH4UCOkZ8u+ZDrVItTwXQTCmFtjMczWZFYGyMWeYYNHSrCln5R hBqTIlhHTIrfl9AndAORJ3RBJh2cT4jac+M/DkAN0R/ENKi7imM7jQFDzy+XKC1+fbjB Nm+AUSuo5bLFhQv3SfO9zCHr1GkxdkOf5pllGyWN+kcQObCxtD4xR9rJ9hvPWuacrEes LhWA== X-Gm-Message-State: ACrzQf3ULMFnjR0/HFU7uQIycFg1TadEwI9ABpqCiyFMMtCJ6EgUb61i iPgt+qNTGFMQ66loQjARFd7wANtqcAOhVw== X-Google-Smtp-Source: AMsMyM6ymGZW5JNxAp7KxFyuWGfvWXrlTc4rfnZbQLoPCCxoojMk2h8uS3pfpVIuEc5VLUnSQOzZ2A== X-Received: by 2002:a50:fe0a:0:b0:458:dce8:2b6b with SMTP id f10-20020a50fe0a000000b00458dce82b6bmr15851350edt.84.1664968551008; Wed, 05 Oct 2022 04:15:51 -0700 (PDT) Received: from Mini.fritz.box (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id w13-20020a1709060a0d00b0078b83968ad4sm4845480ejf.24.2022.10.05.04.15.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 04:15:50 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Po Lu Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <87y1tuv851.fsf@yahoo.com> (Po Lu's message of "Wed, 05 Oct 2022 19:10:02 +0800") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <87y1tuv851.fsf@yahoo.com> Date: Wed, 05 Oct 2022 13:15:49 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: > I'm going to guess that window_sub_list is returning a window that was > not marked during GC. It's a problem that also exists with my > incremental garbage collector. Does this help? > > diff --git a/src/alloc.c b/src/alloc.c > index 419c5e558b..522925d248 100644 > --- a/src/alloc.c > +++ b/src/alloc.c > @@ -6634,6 +6634,9 @@ mark_window (struct Lisp_Vector *ptr) > mark_glyph_matrix (w->desired_matrix); > } > > + if (w->next) > + mark_window (w->next); > + > /* Filter out killed buffers from both buffer lists > in attempt to help GC to reclaim killed buffers faster. > We can do it elsewhere for live windows, but this is the Indeed, that seems to work! From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 07:24:12 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 11:24:12 +0000 Received: from localhost ([127.0.0.1]:56099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2VY-00077u-0S for submit@debbugs.gnu.org; Wed, 05 Oct 2022 07:24:12 -0400 Received: from sonic306-20.consmr.mail.ne1.yahoo.com ([66.163.189.82]:34039) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2VW-00077g-9H for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 07:24:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664969044; bh=f6OpFyagHXMnnKYMaQDSjEfbn7Ex1bFOG4BU1TrMZb4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=FHX7luzfSPEUmk9Msb2Tz6OXp84d/q6evVYuW6h0uKTUzmGi52OK24jXLL2iWw6QnRyFwzjqdEWF8C2t40MnTx6gM+d1qv0HiQ5VKmKmExmi3LGlxmOFGkvSo9Qv0GFj2Yx2w+3Ps2IZ0xa1nVGfSew6ufFUiLNnwEhqJOq90R6Ydlr9wdabnq45VpgBUz5ZF9Q6RFNZyDg4Z0ZU2ZMrsXife/48OnsjTN6TDOfr0P78eUHW3n5N5zikFDiAfmTrtwrHVfPQQl+xbYZZdJ9GBXIMr3zvTWlt+DYn6r7Lcs+6pGFQxM5K5PGmplmrJFS/fpomeiVkeziAP1JE50dyNg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664969044; bh=nLD1cIPgkNaEBizasx9OfwXqaIs8s617cpYHf3lpQSc=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=gDWQl+Zc9JZamyKGGLUFlX9LbSc++7vBzI1NJLwv+9PFD6zu0oD5HzL1gOQABzy85gZrbdc4ABm7b8XOOCvgtXl5IyMXZdy3zZF3kbe8jMPf473fc0KzJ66GqKvg3rzn5JjW49ABi6lv1Pk1PlT/5Rjm6bXb6Uby5Q71m4K9k2LPwmtngWJqkRPlqbAKoqVmBB6REAVmHQ1UGMyC3nQ1fv1F4NLvFIDLoT8VhOP85SSbPIFuQ5oDKKkWKPii7zrCqZQEevJNY0We7AyXg19s1vDnHFKPaA8SmbIGvd6V1yijEHPdfOs/YzqXtNjiQYCU63Y7fPu0Zb8R42OP81WwkA== X-YMail-OSG: iQfAp4QVM1lp1ngNCtWvJJrOzRB0m2b_KbRLOL3U4USjdMC2_.lg0QVVHCdJCl7 8TUM7EfCtsnnRU0nkaVJPfV7uR5PBtgQzfm193Suh3ETbewptQZXUnAEx1aUian0AYVMtCMFYaJk ok.rOpIyWkLKBrPQW1O6SqkX2e3k12SU1RbVm9xmR69XvJ8sSmdhgUG8epGLR5PnZaTWj12axNfo J80Zy4kH0KjbB7tM9JsopiU.Z8J9D584ndpo1gFVOB3g8GaIQ0bjbhwOrhB6iYWtwCOfQDCfMP6j ZV2EZUGo6BHkm6XIXGFXoF3Zejj3mki5d5Ifo4zSWpL32wxh95TxhBB1qIkxx5leuP_bEf6Fg4Tt ONRL63W2Rk_WPjTxt9o3s2RJFKDjQffybJCrtVdASK7Xp9UvwnkT8OrRQFUKGFmYN92OzELtXBuv YmQk2z2stfo7n8.IKUP6gSSsNKfm6MHf8oEZ95HEb7TO_OGYAESOeV7m68y2capGXuJV7ae_b0bX nFERVIEUDdfua5HDr47y8eRfgL_fYoxkJuvnvJqhotBINruku.5Xfn_yQOX9bLuSLQSkKuGb5No5 KcsuDAy2jN3swhnbe1DxbfzqX2BGkjh7R40t3vLNNe3CZ1wph2nNu_gULKk4egg.AZcyfX5l6iMC cndGsXLeFTR1qFKitgt95rUC1cpYMLaYkl5Ou0dqeRyOFaGvAxcIwWZtFu1xEP9LHYy6ENEi4jbm MmFfMxwNcka5K8NlHEfHwRjM4gCpGu5nOvubxJg7domBzWm882Va7hk1JvjscjmrwFxFST5Lm.iw 4g2h0p9pDsCzpz_Yr8ndDJhjN8lLTR5FAfSZNlOlCJIEv790lO1oWyPkINZhx9danDrKhZgwhXsJ ajv8oxDNZ_GtowjUyJ5TrKL1Km.V51hHTFZGY07_P8K_KcKjH4NYd6N6Nm.dmK2IHnvsPmBQmoBB lbuCOkWGUMreQJbpUq3.7_CWb0ofprv1TLjvQrCBYASi7_1mUgzy3kbwfSjZGIRWu2TzglgNygKv 1gUByFijAqowcrVMctlhz_dfcOig1J91vcbhK148V6VpebhqZp2OtQZUgpuEUJJa9t1uxewbaIZT tGUCkKTM01JRNUAOHKMzLa08PaJ9j07Qh2OidnCZnr7f9FLeMRrD7pVbTrpWZVrN5bSVDvIGE2cP moStBsPMpmGZXAclE0IW8Zdid0ZHwVaVrGlmUZAgx125BGMPIuat6wYDZOUI.tssnM0EtbIsal.7 c6MxhC9VjOgGxHx0Ttzcqy2NlPsxi4DPFEI_XjKZe6e8y9A_wP3b55GuxOAwFMk84qLa8saDHuZ7 FHkPqa4VzXKdD6AshOyfDghZ5Ij0VdmAFRhkdiNitoKpvBSJp0YNRiU4xUAdO_ijptBBmzx4m7Jh kp5ISh8VqyfiB74NRjU9CP73ea1ORBT_iytnHxupVDIfLS9iUzBVrsHk9P0JGLAQlyGhjT1hOPyr iBe_lqXmGEo9K4X3W9FZKj0LH1Q_DMCybvLBI2_Ih8oESVir7YXAr4yd_U_d4Layay1vWkG_T6IS hYClWLwpIyxQIbQTDsbqEiilQLR7FhuegoV74gCqCQawnbY5SxP9Mt7CFKZDclVCtLe7.waHyhEu pTtkTAugMo9llaRudxMjAosv5SvKMA24hYTdpvCICwNPJKhjKkkQk4hVPME8pW7lp.vpU0NjpEIe ITN30EtfmcimeTv9G7ebIEuBAQpA8D2_jovYOTA1B4NyfM_EB2dSX3w954TaWBEuWTNoaJpbYog9 JcYyAAMXNfjCuIQPCuaWwqctcz99nFPrZewjnmDEqCQtX6AT.d5z.alSpXXLU8jnHJ9Mt4te5nIJ hIZIRBZwjDzawTJXaxMoXwnRHK9HhhG69PizH2X49mJ2AHUzp3IKcQLgPa7FNan3YtJnjYYzks4g EfupRijjBDSK0C6uTIMaMr3PcuTFFrwHyDXxAqTTfVLgj7ZEdhCA0qdPyTUlt5qxvPAhpIXTGPLE 6W6qHCyKPOewUtAWjsJRkd_Ia.IILHTrpEeIySJS0CxAlp1rjM6kUWhSKTOZEBQd28QC_sf1Fn8M lRlXqnQSIrl4nrOiicRuE8LbAWr7fDqWfcMWIJSThuMw8MxpZhCu3VazqDJY2ef8tkz4cYjnUtau TVAM1D8BRXAG1PqZ.Ua7tqCzHZJPgjDeChWtBuUNEnBJXue8CeJY3YeOxg5SpmppICimCxoahF26 QFqSHqZBGbdMrPE7Ot2uy7kjjRkaciEyOXYUYR1lEtbJq7r3Yzhlbj8jQ9ATl3Gx6vnQSZ9Gu6Iw GzQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Oct 2022 11:24:04 +0000 Received: by hermes--production-sg3-cf9dc7f8d-f6dcn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 666d807ab56ec92c7b2e9efb31e5951b; Wed, 05 Oct 2022 11:23:58 +0000 (UTC) From: Po Lu To: Gerd =?utf-8?Q?M=C3=B6llmann?= Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <87y1tuv851.fsf@yahoo.com> Date: Wed, 05 Oct 2022 19:23:53 +0800 In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Wed, 05 Oct 2022 13:15:49 +0200") Message-ID: <87pmf6v7hy.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20702 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1152 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Po Lu writes: > >> I'm going to guess that window_sub_list is returning a window that was >> not marked during GC. It's a problem that also exists with my >> incremental garbage collector. Does this help? >> >> diff --git a/src/alloc.c b/src/alloc.c >> index 419c5e558b..522925d248 100644 >> --- a/src/alloc.c >> +++ b/src/alloc.c >> @@ -6634,6 +6634,9 @@ mark_window (struct Lisp_Vector *ptr) >> mark_glyph_matrix (w->desired_matrix); >> } >>=20=20 >> + if (w->next) >> + mark_window (w->next); >> + >> /* Filter out killed buffers from both buffer lists >> in attempt to help GC to reclaim killed buffers faster. >> We can do it elsewhere for live windows, but this is the > > Indeed, that seems to work! Right. I've not had the time to investigate why unmarked windows remain in the window tree, so I have the equivalent of that in my incremental garbage collector. I think there is an implicit assumption being made (for example, about a list where all live windows are put) somewhere that is being broken, but I haven't found where. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 07:35:14 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 11:35:14 +0000 Received: from localhost ([127.0.0.1]:56104 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2gE-0001CH-6P for submit@debbugs.gnu.org; Wed, 05 Oct 2022 07:35:14 -0400 Received: from mail-ej1-f47.google.com ([209.85.218.47]:43522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2gA-0001Bx-98 for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 07:35:12 -0400 Received: by mail-ej1-f47.google.com with SMTP id a2so14696887ejx.10 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 04:35:10 -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=BWRjya7fcq6s+44vnUsfNHJQf3F6b44hDlGXGnFL1A8=; b=apq/upiMtxN7oBA+KgSA5So/96bVW8clV8y+4Pity4s6pBcOBu606THgEoxOy6OYRe NKLGkUqSmFg4T/tHfpXwyGE2dm9wKS+63Ot2Yciyje8ptVDwsE+ErNBytNreD2TdTnbS YR5plwoNnDme7kvrBk9ECSFs6VMWHeJ1axEzWjPnI5UvShMbkz4SUKfXdO0iykG4pHkP tPBatairfmdcBpxwHVm+Wi3UQP/N6X2abH+vLM04C8P7zkMzT+rgEAMoM56FH4SkYojU eHClMKmYjoRnBg+ltRWvfVYSyqB7mmk/rellFLAW2Vh9+6B+wS6M49DmpoCv7DieN2OB g57w== 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=BWRjya7fcq6s+44vnUsfNHJQf3F6b44hDlGXGnFL1A8=; b=ioHzdefFViWre2ULezH7t0EgJDoPPET1w3ZV3zxudKr6GoDCmxt6LClenSRs/MaH7m IwsCixH9BP8hrtUUx2UozYu1uqUlPNjxxfseBIpnzyt43R8bTcZkD9f2yT37V0ELYpE+ FFVFB0owXDheO5o4WNluXAJwYb3xALOKCA8hui/l2gXsV3SVvApfl8qlVkdzNlBA1yCb iPb2aaOdPEmXCdFWYxw8A5mmNO3miV06LEJTQztOQmiH2kxtgybOTZrJSR6ffMTHzbzD uLRWOKmoGi6rFWYgaj9BOXtXrgEkO2bJaMiHTDQX1y+7wJxwm/SYB9/U3Yf6JrNlst7V Cmlg== X-Gm-Message-State: ACrzQf1qk45TEd8opxYU5zSrEPfeOXs2C14BQSWybU73KWKa6uVr7RPM y+T/uy7QnyFpBfA55HjVa5WzK8PXo97tsQ== X-Google-Smtp-Source: AMsMyM50HUPBMpcOYfyqHk5eCrwYPW6WUd1ZEdE+3uGjZeO0Ep4CZXc2QkRLk29AMSjH8Ds6z7I1ZA== X-Received: by 2002:a17:907:9627:b0:78b:ffbb:ad5 with SMTP id gb39-20020a170907962700b0078bffbb0ad5mr2519448ejc.113.1664969703972; Wed, 05 Oct 2022 04:35:03 -0700 (PDT) Received: from Mini.fritz.box (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id vj23-20020a170907131700b0078d261f9f44sm1204371ejb.224.2022.10.05.04.35.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 04:35:03 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Po Lu Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <87pmf6v7hy.fsf@yahoo.com> (Po Lu's message of "Wed, 05 Oct 2022 19:23:53 +0800") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <87y1tuv851.fsf@yahoo.com> <87pmf6v7hy.fsf@yahoo.com> Date: Wed, 05 Oct 2022 13:35:02 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: >> Indeed, that seems to work! > > Right. I've not had the time to investigate why unmarked windows remain > in the window tree, so I have the equivalent of that in my incremental > garbage collector. Thanks! At least one GC-related bug less, if you put that in. And with Eli's proposed patch 2. I've added that to my local branch, but it took long for the re_match case to re-appear, so maybe it should be put into master as well, so that more people test if it has adverse effects. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 07:37:34 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 11:37:34 +0000 Received: from localhost ([127.0.0.1]:56109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2iT-0001GA-Nh for submit@debbugs.gnu.org; Wed, 05 Oct 2022 07:37:33 -0400 Received: from mail-ej1-f50.google.com ([209.85.218.50]:34455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og2iP-0001Fo-GG for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 07:37:31 -0400 Received: by mail-ej1-f50.google.com with SMTP id au23so14066202ejc.1 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 04:37:29 -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=mZ1BvcEdSlIRtmOqiCitEbpKf6cIQCwBpjqpT0A2OsU=; b=WVawlT58VAruBHdW6Nktg31qYoPDeL0GmvIGT+Ut2Y50yQf/rZ3t71Ty0GmbZGYj+9 74Rff11ff55sL7Z6Ezq+sFAQOcrnzZ2oKwRCp1Yt527VSagc4xBFfTUSuU2WkHsIqRQA uoHsJ6FJI4xgo+440htsoPaGlU4mdu3B9tNs8zihEDj1SD81iAYe//RMnpQarzxr+nuE ktUpVAslsIzLKyI3R0xPO2sGW9xtZVpJYqm/x+IUlGfW0PQGjJW65nrTNknHzNj1uBHd dY8ZhOGJaSGWc49NHCFqazHm3LuqsnipDt+X8r50t/n4hwJNBZ1twJ1OAmxNtLoqkCpg B43g== 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=mZ1BvcEdSlIRtmOqiCitEbpKf6cIQCwBpjqpT0A2OsU=; b=M1H8gsdHCewrZnzOXXhEJI3R0DPnCvFofQZsk2QfzrYbXx2vHahYrkqL04XtUvwzqs orcUxjqtn+Y2k2weHWX9ZNCYIyMv9gqJO3T4JBRC9c2HxvjwEHHnDuMMiio4dbG1Rw8A jL5qWvmn86ejPSOefd18V3oM/3zW0mzlqi82RP28cHpo8tlI3es/lczx5qjjxU18gjei kSTuKCQI074qZ51s9ejuiT46scKMCO+3nHRIRGu+Dsp+T3uLznHGdopY+9vPZcuvxM2D cyNVM3iPXZvQ9QcbNCXoks9/C1xXbwEhEUx75koSMgCg3Rc2g42F75VCzHO6P4S/uJct 1K8Q== X-Gm-Message-State: ACrzQf2EKJHg7nURuWC+q0WHvojIh9WB8apibQdvleFccvJqbqwaVwkw XZsW+WpNSkFk3e94LdNsfOc= X-Google-Smtp-Source: AMsMyM5fKnrPAYcQ5nhR2ppnEP4wg5IqMDk+NKlPscloKs5dTQVQ4ZGB193CWZg+Tou7ZswjW8o9JA== X-Received: by 2002:a17:907:7639:b0:78d:3a61:2997 with SMTP id jy25-20020a170907763900b0078d3a612997mr216788ejc.82.1664969843959; Wed, 05 Oct 2022 04:37:23 -0700 (PDT) Received: from Mini.fritz.box (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id z10-20020a50eb4a000000b0044e01e2533asm3646750edp.43.2022.10.05.04.37.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 04:37:23 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Po Lu Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <87tu4iv7w5.fsf@yahoo.com> (Po Lu's message of "Wed, 05 Oct 2022 19:15:22 +0800") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <877d1ewnx0.fsf@yahoo.com> <87tu4iv7w5.fsf@yahoo.com> Date: Wed, 05 Oct 2022 13:37:22 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: > AFAIU if it is particularly dangerous to modify L there, then input > should be blocked around Fmemq. Thanks! (I'll pretend I don't know about this in the future :-). From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 08:02:36 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 12:02:36 +0000 Received: from localhost ([127.0.0.1]:56134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og36h-0001xk-Md for submit@debbugs.gnu.org; Wed, 05 Oct 2022 08:02:35 -0400 Received: from mail-ej1-f45.google.com ([209.85.218.45]:47070) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og36e-0001xU-Uj for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 08:02:35 -0400 Received: by mail-ej1-f45.google.com with SMTP id bj12so34909615ejb.13 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 05:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=OGV1Ht381hXSEchaAd9+yq5PLkNC4y40ZJQSpLnVwAM=; b=QN5L11PoU5GBlUOrcuYClqXUL3KFUwE4OwLXLJH97U/9SdwAlXUNXnwoyDGR4JDR0b 9eQZnmX+nyoSCBLyqeitHy+bC4/JvI5wDH259Z1p1jsGo2bkAiq2YZsrZ0I6HurLrZJk EaZmynFa50A0k+kN+j7dujyeEZBmtdntuBCPwKZqAHy6woj2nFIphCw/5gXmmQckRo13 503E7r9kw8ns25ZRr2yqq//jIrSxBDHYK7D6cU+pPECNd2cTrA6S0nH/FhdjTUzzArkK vTededZSYzh7gKPmjqJX/4oEic3nDoOSE88LTcyO2o6H3P2wYRCCHqjCYqO9BavEEW2g Hw/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=OGV1Ht381hXSEchaAd9+yq5PLkNC4y40ZJQSpLnVwAM=; b=AsjwcRj6qLQubnbNE00Svew+mM/EAhYBEdj70FBT1uUDwzXnsagTkfKnUZzFTDCEDU tfd9rBhtx4/o/brAo1UdMDrySNRC3+WNtlxqggMkjgM5SlAytlcfLzJ7GPXK/rwwBCbA FWdIjUW6KWw1/GEPTjtUy3R6EIXpzwG/1UFQKdEu6YKB1bJloOzyZQ3pAylNCN56wOgw eMXaX0fDt8qtGubAF9RBFryb7aOQEvob8YSBgp+Pw+47GbUZsBMg4RZZzvMw7HlF4rrC ewtOqZHmaEjKvu2Xg+zxQsDm2WHrl2f0OCCXqzEaFKnoOKBZdHFeWJYw69UFxnsSZtEw Og5w== X-Gm-Message-State: ACrzQf3yOqA2dComMLmJ0NAUo+kmOgNfV7t5V1XgLv9aCgho6OoGprvP dg1RIGOyWohsJvcP0SsvCAA= X-Google-Smtp-Source: AMsMyM5Nin2DmclBxrCFpvTC0b8rFC+RM6sj7/5xiGijzvAUyzT6Dsf/oFCMsz6c8sbKFN1h++/SXw== X-Received: by 2002:a17:907:948f:b0:78b:5a89:a23e with SMTP id dm15-20020a170907948f00b0078b5a89a23emr12212232ejc.421.1664971347103; Wed, 05 Oct 2022 05:02:27 -0700 (PDT) Received: from Mini.fritz.box (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id r9-20020a1709061ba900b0077d6f628e14sm8516344ejg.83.2022.10.05.05.02.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 05:02:26 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Po Lu Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <87pmf6v7hy.fsf@yahoo.com> (Po Lu's message of "Wed, 05 Oct 2022 19:23:53 +0800") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <87y1tuv851.fsf@yahoo.com> <87pmf6v7hy.fsf@yahoo.com> Date: Wed, 05 Oct 2022 14:02:25 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: > Gerd M=C3=B6llmann writes: > >> Po Lu writes: >> >>> I'm going to guess that window_sub_list is returning a window that was >>> not marked during GC. It's a problem that also exists with my >>> incremental garbage collector. Does this help? >>> >>> diff --git a/src/alloc.c b/src/alloc.c >>> index 419c5e558b..522925d248 100644 >>> --- a/src/alloc.c >>> +++ b/src/alloc.c >>> @@ -6634,6 +6634,9 @@ mark_window (struct Lisp_Vector *ptr) >>> mark_glyph_matrix (w->desired_matrix); >>> } >>>=20=20 >>> + if (w->next) >>> + mark_window (w->next); >>> + >>> /* Filter out killed buffers from both buffer lists >>> in attempt to help GC to reclaim killed buffers faster. >>> We can do it elsewhere for live windows, but this is the >> >> Indeed, that seems to work! In case it matters--I didn't mention that I actually used the change below, because w->next is a Lisp_Object in master. diff --git a/src/alloc.c b/src/alloc.c index 419c5e558b..826ff1dba5 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -6625,6 +6625,9 @@ mark_window (struct Lisp_Vector *ptr) =20 mark_vectorlike (&ptr->header); =20 + if (!NILP (w->next)) + mark_object (w->next); + /* Mark glyph matrices, if any. Marking window matrices is sufficient because frame matrices use the same glyph memory. */ From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 08:05:27 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 12:05:27 +0000 Received: from localhost ([127.0.0.1]:56139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og39T-000226-7w for submit@debbugs.gnu.org; Wed, 05 Oct 2022 08:05:27 -0400 Received: from sonic315-20.consmr.mail.ne1.yahoo.com ([66.163.190.146]:41442) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og39R-00021r-3F for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 08:05:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664971519; bh=emRsUQSaDDIiTZalZS5HOFZq2mRd/VRwf9Ef6jP32fA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=rgB0gT0fK+LxvxygmiNPnoOSuh7UOO1FKwykU1KBcrCU7ZtOFy0KJ4IhZKrxJI6ymHe1PcT6noSLyDlU+ALAaiwiY7qNnjvYfO8YYEJrEVEKQGDNsaXYdN52FMSynIUmKMjyNR1IbDnlcZWlAozvxApXrTXGeP9BPDXRY0kxdEoPGsJTTzRK34s+a7/1u2691tKLc66EJ2ftLPrJY4GI2PNysowu5pfifZ9czUmnFNc0+8gLyrm96gXtIdxt8hNa25ox1XKZ1pwD8OHH1RV84FLhrD2jvsT/xva88jLwGM7F6jojy+T4CaUfFYnnZnZYssArpYwTeNCL9KDOCihfuw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664971519; bh=3D8QK8xaSR7Sz7QmfON1t00zuhn2ITSAdM4jK2ShPPL=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=PDopys9Q4ECiHRj8CHjRbzKhj2zD/OJVrwaptnB3K/+4ShXxNXJiUcCWFkUnL4FFobjvS+Sxk0VUDOkUtZlUJ3ywM9eh+DorFnIB5avvi0UxyXDFP0gLvldWlIRyWrsGe92Yzg2AVNzsLZdZ+hbODdbp7yWgR6BW2S/042BBqK5YOFo1auB28ZRcPwZ8PYEtBQsetveaVqYBP3dEIe1dt8nCjsE0G72/kIAIQbvnED62qDN2lu+0pSQiQ0Em7EynrzPgZuLg0lEjSYpJEgfV0HuaTjlYaUnSkgmQV06F2Fc8MSuLFbyTih3pHtOEGblQKbaVz9n3e+ynD2rjSdeT9A== X-YMail-OSG: FY6eXNQVM1n1lC.ucZXotc3frVY3lbAZy8QeUsTvZq6FlFRJaotigHoSxKYhLcD ZJHPwniJhKO_nNaKOjkWPuCGHLt.nMFNletxhSTuJI0O0wJQT71FRtVQ0beXm8qp3.EzEv3l_LEy 0YaWjUhUrXDCzt6YDMziUGUNeqE_XbQ65Pf9jl1FgGPeI8_OU6Sae76gikKhGu1vy1epa9YeZle8 2C.z6YX0__Aqm.4y.4bECoe7vbb8xycFgOxLynYXRMa_DpGtWNNfHBrCmm7hE.ZJa5.sEfq3jmn1 Xfyya5SBf0WEHDAUHrR2vyH0whIL0aLVi3jmsaBXYCUy7skxccz_2Zjiy9xES1sP4YK0o.vaePOO sALaz53ZrDb2yL71kRybgVQnVgJOGYS7fAy.bGne9QjEt_t98Yjxsa.njPT6FjC15xm6BchsUTKV naZebFB7FRGY7yHBeI_YdUMVcCw_sES9mNL.mVC2Dg_.cOHSKMjteks11riwPK2Zwvr62b10KbGv HNofnxf0RbMSPHe7wprJ8eGZl_BGPeXit.nPIoLQRs9j5VX.6MXJH6aTbni.LJ1wgxVo11lzrDeR VHkvvvBCe7sJwMIYaNHemqgSNVqDySIoT9Oe4GV.Zf1hmFvcXGZuwsJoIVrg6BGc8B6ig54qtplS mj8CJtZajijrIUbnwUGVInNbhy0AOzdEuGKmjgbQU4EOWMO4MPMekvzV4UdRGnRikj_dUA.g4xOI aE3AEcwmUc2JJeV2SlCI9JCN2STh2dnLClxGJkqeNraV0aKWIwRinM.7ijxUm9suQiD.IaPabk8z GY5BrJpiZooO7v_3uJkjv95zrAWEvnTTYT5WFau7JS8C1V1Q77KS9aUN5.CTCY3Vf6uKoRPqCovN AboKRjQ6mQ45QEhwERA6Zut4teqS0UyNIN3bImAbfrh585PHn_PTjGUbivsfsJTGNGjQrkRvs3QO 10NWJSdZBF8d8VS5.bL5746Z7X68sZGT1M1.e0mDKdM2nLQMIB9YU1jPemopd7pQmOMq4qWgFFp5 xbjSc_MtJImzhqeQqF5Gchywcd4qZNV59p6EwX2JYJAZBHhOgWPh5nMBiscdkznpNkRKPrbmi0F1 EOmJoGXrvgPXuRPFlzay_fdcZc4xY1L0d4YOi..GIthfmRDuufx4Z8xf_QdHhJM2OhDD7yUEvtAy xc0HI4KTiUCLMch6S5NQFpY1fimiTnTa_TL4surqFkuMXQ1qoqeb2lB_5jHurzSR5WMc0pYKLKOF 8hTpu5nT7P_f8guZKjsahPbCKTK1SUU8nijHTNAAQBW2o_x57GIeP0MoUFBBup42JjUp08NWY3I3 CPRbdqweD4qQ.CIaRa7rPs4XP.rFYgARIcPcf_x9TJ4pQMeWuZ18dHdwaO_oo4p5O1m.jACqEcCi Ye2Ior7RdiQLGRI999p8n4ProBd3OWyfnf6VSh1X9c8D1J8.gvRbeTd7qxGjSEu10mDIuIkzO8zk YUFpk029TE6K7SRwj8jcyzx2DxNexi86xm09U7k_QbbON98Uel5ET8GYpkBzQec5PUEy1YXGAGEP XZcQJmWxQZ1r403zVo2.ImPom_KEumbgjKS14H1e4FiUV0vKkTgYJSENIgnBgp7Zl9ZJXXWu5UTZ ncih2psIOJnuCe3kr4n4NrJLMQ8aeQc3r7JuJTF485jwucBV_bo.yz1QCz0D3IuHGYzHQlocxYRU YXr9zSt.9suaCkfbtiLIF_X3Ih0uNsHa_W1Wv6hw.pB_H6Q4eiGveqQCcoPunodwu1_veU8Nwc4i CsPlueYuvEq8Txo2xCCbvH60Ff.kShoAWgC7Oi4afE14FvPTTYxGJnURmDTIYuFy9dwT5qucqMsl W26VcHTua39ZS2Ey8k_7YLLAyXfUPyfypozYlrRdaEiDNXSry0q1RPWYyI14bGW4tJ8UsRJ9Rmbp XoIFYlG88Z8ohz5PPcYYdhoKW.dDO8Uh.zz3mW19b9tfSXFT0DniyZ5W.rOlCxUCTYZ5w_e6Wnet 1Vpye_p5Vrdz5Z4Dzt1ipbTUJRrZS_Pjgtf.83_h82vFPO0MX7vDHHmlbP0cpc9lidzrdPwtBX2J c.PE2FHMCga9E4InCZs6K3HHeQvsqpmhoK_bI78c5FNpSswvc1Y4bCmDRKOK1RI3TzSoS._uM1lK k5dnuUt7uy.kcNeBDpyABddOKxPy5qQex2wPIWoUJ6JFxv4TYV7dOtsx4fFzWlwn38SIfVs3gloL FUkwxjKRlgfNVpbNxNP3prsXZRZnTtsM5vIuCnUkrPl1c6rQB9PMZO9xJzX.qP2iIIj.riFOGy.9 87A-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Oct 2022 12:05:19 +0000 Received: by hermes--production-sg3-cf9dc7f8d-5h5f2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0d2e388753e738ee365b43fe395c8f54; Wed, 05 Oct 2022 12:05:13 +0000 (UTC) From: Po Lu To: Gerd =?utf-8?Q?M=C3=B6llmann?= Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <87y1tuv851.fsf@yahoo.com> Date: Wed, 05 Oct 2022 20:05:07 +0800 In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Wed, 05 Oct 2022 13:15:49 +0200") Message-ID: <87lepuv5l8.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20702 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1131 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Po Lu writes: > >> I'm going to guess that window_sub_list is returning a window that was >> not marked during GC. It's a problem that also exists with my >> incremental garbage collector. Does this help? >> >> diff --git a/src/alloc.c b/src/alloc.c >> index 419c5e558b..522925d248 100644 >> --- a/src/alloc.c >> +++ b/src/alloc.c >> @@ -6634,6 +6634,9 @@ mark_window (struct Lisp_Vector *ptr) >> mark_glyph_matrix (w->desired_matrix); >> } >>=20=20 >> + if (w->next) >> + mark_window (w->next); >> + >> /* Filter out killed buffers from both buffer lists >> in attempt to help GC to reclaim killed buffers faster. >> We can do it elsewhere for live windows, but this is the > > Indeed, that seems to work! Could you please replace that code with: if (!NILP (w->next) && !vectorlike_marked_p (&XWINDOW (w->next)->header)) emacs_abort (); And see if Emacs ever aborts? I just remembered that the old garbage collector does not work the same way as the one in my branch, so that bug shouldn't be possible. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 08:09:17 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 12:09:17 +0000 Received: from localhost ([127.0.0.1]:56144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og3D7-00027W-TH for submit@debbugs.gnu.org; Wed, 05 Oct 2022 08:09:17 -0400 Received: from sonic314-20.consmr.mail.ne1.yahoo.com ([66.163.189.146]:42076) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og3D2-00027F-CO for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 08:09:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664971742; bh=Qb3ED++rfGoTSsuAdWOTPJVeB32bouD3xe7XfuKdg74=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=Z/OiwFWx/CfIcA70NEjowrZDaXNxmgR6cXq90A9Phoulp+o0d6iHTKpclVdOsiJoa8t6cu+93SwnKhub2AaG6RIsgHCktfh8wQmvmRVldoHsBQ/Find6L2VGyJKXpV6+YJznE9gOdFIkDvU1of0ucDHl22Jvd1Jik3g0pVN3ZARaDUvHqMCMs8k5rNXTVHc0P0bPFGQU8R+BvKdAT6K1nfzu8IdqU6+rmlkn40SZp1MT6Zk9HXqL4TBLfY6OG2N3UOnlA38i7m8s4AnFFId42ZBSTfZP5xblJP5l9BhAAyn5P+862B1ma9wuCPrL3EIBRD7c4tMhQQHmjF+2QsHDog== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664971742; bh=pWaLYnQvyFU4JppNQnUs1cjvWNUkIgIiBSoIaQGLr6l=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=d7s4Dg9jPZBTbn9dHdqN37TVLrm//gQ5UadP01XL3HTHwX5h5orQnSP9fSEwIJihaQ6GHX29t1yrVFD/iLNLlZpeDC9UfB/LfEzF5/dzIMObuw1r1ot+qg5Dg9ZbXFm6UDBFMGRFAk/ZWwCR48+SkLSBlq3H/KyeIMZ5pwvopjOxXMuaZ0xz39EpPctpX9w3R0tUta8ZxCcahuoCRcOi1GeUtMXFWk2t50fIRC7kPmT9jhj0lWN6FDE/ok35wZTUwT6E65q7SYZUbTlKlxZEBwPECAnlZiR3cgYxlDYde48zPGw5R9kFUM2ILZ6bom6W3pFHrUswnr0pTFxAm1RSiA== X-YMail-OSG: m5F3AVsVM1kJrETI.IaihggmVk7gpZaT29KyQIWsZRMdc8xC13SkfudDsBGoC5u yDKBAJC881nmB4A4FIEh9rg5WmrCa6wmQHNgycNSGx_SfGMzLcnvhC2h2gQlGDhqf8kmNHgwf6XT 8r_bEdRpieFTyxofF8GgutTwfLj.TEDQ9swXrBcmvJwIsq23RA2qKbRufq38n.Y_E9I4cKEZm1pE Mzfo.ISJZ85WJQLJ0GXtSX.9IF7oOwdehGZGT95DWjDh6KdV1Q2rfJbUbgD4d_FY2qAwDhTLPSSR 4debOfRfnlrs_63DUqPmt3_3wL2qlytzVN34zp0rOsVsG_M1DWwStbPhkkTkAqkpxgPBQRZa8BAT EaY4ahzY9ypg_acow5rp6cQeGrPtJzdTBJN8dNRoowWR93miNbJgIMT9TxH8sg2YICU9Ag9jXfF2 AvWHZkm7G1FR3Kc02mNLURNBsPIzqQUAQcXJc3mj78JBC6loQsfZcqCdFRfubAa3CM6W.7FEk0LU 3AYhjUBxHmBwL22OWnAaEBVbirZAHSb0fSF8C_cy3Vh1q885gd1nALZ4XBcRH8a5uEnwiDLSRxsC ByBEcfWaxgrhHyjRF_Ls.MiRAomzgpEAr7izPYVk9oDOI9kxI83Di7Z.naDyy4frvrdNkSgKFaxB X0_bONy5sgTIPceXkinS4pFLG0AqjE42Z6qjn_GggZq7X5bblI62pxueBRJybuJHZ6m8Jf6W6UI. cDp_TFxfTazy6.zytR_8rVyE9NJaCZW28m..QLJwys_hlK8Kx8mlmNM878dbX0wWIHl6OTX9floj O3CQ36Bp3XBF0AdixpujltnNY38KxRwTuvBzkqyTRcqznz4RfY4NtHypqLcGUlOdTFtU3MGj.7El shG.1BQEo.u6RxZC9.D0X0gLbxx11GRMj3WNcImlxyJ2F8_l7HhJXmB4pX3f7vuVnb9TKWApaO6B yoXd1w3TbkaqLCRIw.GYps.o8EYn6adRHNEDPzHnWMniTVX91vqyc7lYDSnkAg4oXK82yrOPhUKx sBpMHjjxqNOLhgEQjPpC_lRFKokA00whgjtZj.RH3zcJ7t.uMlKtzHSulS1IdlHWvulVkpSpBa9M SCZujLdO3w7n68G8jJQZUpMQGRIsFYsVdXSHe0vOQuyTM6W.OCjbzpMYilQO1gybgF6S3yEyZk4w dkwHp_HPuTc2119lozX8wuC0d9vU3J6Gx8rUvbSTttM_4loYf1dUam0R7Ze9D.UtgxEd3BHjJsCj ukIdQ.VsPnG3Dytu0EHCCwt82lHT724s3I8_lRBPvXE0lyzC_DXGIFbsaPqXPUbjYJSk42YMESPO KV4hzANPntG9HirLuYeFL7P9Uab1AuRLbI0cS4FrZLntsS1yidBgQ5ZH2D2E13UnWb8XS19Btdx4 iFxhdJofJV7q05ESz7BKIZIzkgZzuLpwtho1veZLt7MJz7uJmBClIRuOk3Bf_KNXUHgBufgpB6cS A.EAy7GJwxhzgRMFf1xGbLN3k.eCLAl2e_9sEIHeAAfHzckRWw8LG168Nd3DsWQ_qf_taXUarEaP 8eZLRnmDkde_TG331x_cC_fRgB05adsevLHFDptYKW1.0trGi52xMXD2BwevKXJGgOlHFNaFO0ma Oqoke9wS9UMRhOwh33PKsFOEe9IojFVE1Dlk41U47LaYpctRy51oSx6Ln9tLMVicUYHupJVI8jnU yktsjS45FtKtGfaie3UgegRjBPggxyrrorv8ijIooKh2uVnpJ116ZTaWUINb6.7R2FeeUoPbwKGx n2ANjzND1NG1Wtyg6k7WGNnReoE5nqFCz6FNnWY6KxAB8FrSpg2ze9GigO5Kq7ZVT2.3WN7jYkBE egHFNwwQr0Y0ffIBNvqOBYnieu8SuYbNXOrNFGS2iUwy.kg_pGOHaB2EWl4bqayRJyfP8BvsJKdR Y3rArZzuU0Na3hSrHooUIk3ug1DlYoG1UoRkkFi3fsmzr52PHfoEe7l65tCaiDuGj0drBzznu4jW 7Rwed8nozfuMLLgDnqLXlqYDamlZsoofTmKATYUIR.vWwVSxeGghirqtv5sqY_CELI8SLNubggoS .5mmD2cRvq6HxEe82A8OMcWB4jw92VzFaVoBFLD8oyYG3jDncTCmGSsqcx6LXoxyCL33TYnrUpaH lFY7igz9cmhhjgX49fehY0XJsEDYdymVG.40IOP8IIYK9Il_mZ3IOhV3LrUgvEcJqiUPY4U7bo0r yNEQA3agqjYuLt5kljPkg8Rg6nuqHhwQcveW9HSpH0KAT6aWVzLRhcjNO0howO8RYHy26cfger1o - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Oct 2022 12:09:02 +0000 Received: by hermes--production-sg3-cf9dc7f8d-lcfnp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1c9996386fef1b9733e2437ed79cf065; Wed, 05 Oct 2022 12:08:58 +0000 (UTC) From: Po Lu To: Gerd =?utf-8?Q?M=C3=B6llmann?= Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <87y1tuv851.fsf@yahoo.com> <87pmf6v7hy.fsf@yahoo.com> Date: Wed, 05 Oct 2022 20:08:50 +0800 In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Wed, 05 Oct 2022 14:02:25 +0200") Message-ID: <87h70iv5f1.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20702 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 485 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > In case it matters--I didn't mention that I actually used the change > below, because w->next is a Lisp_Object in master. I sent another reply to that message you should read. w->next is struct window * in my branch, but in the ordinary garbage collector mark_vectorlike should itself mark all fields between frame and mode_line_help_echo. So if that mechanism isn't working correctly, then we have a bigger problem on hand. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 08:32:19 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 12:32:19 +0000 Received: from localhost ([127.0.0.1]:56173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og3ZS-0002iy-Q5 for submit@debbugs.gnu.org; Wed, 05 Oct 2022 08:32:19 -0400 Received: from mail-ej1-f54.google.com ([209.85.218.54]:35572) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og3ZP-0002ik-W7 for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 08:32:17 -0400 Received: by mail-ej1-f54.google.com with SMTP id k2so5169444ejr.2 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 05:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=2aup/3+dADtR9GD2U/aPEhVLENU5uRWaUFs7bOblFRU=; b=LlYMEXddjOCXh7xFd4Px0rV5QFcYsh4zKpHm/ULBaJ7bs1SPfsXjZSpDgAHqgQ6ZL1 p5LLCHBNTU2gkuLVUCdSwgrCYJypwd0SpbEh+Aft0vSSaieaAGu4caqHC/q8W4a/4TLA CixJSItXUBWe0igjiHs8rAfg38vcS+Mow6hFatWVjsoGsjuLpjeCEY+Kd5n6zQ+gE4EF s1ncfQ9ozJgppWpyu6ieOIIcfrW1dcU5kczDxr5hhSJvxA0oNkL4ON/oVh3Z8XAjW00w C44jLNvG5y3hu6gkfgL6Uyh8MGtYfqw2RyiSYuqJGhnWmFESCGOBvO2abepNP07ALMlB 6x4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=2aup/3+dADtR9GD2U/aPEhVLENU5uRWaUFs7bOblFRU=; b=6y373nQUhqBX1yfXpIG7pxKViRW7DYUkuEI3do5oEzt4xtf3VTwP9dSW6LhlKSMgu9 UAyzDKJUPbhYteMCJKBaZraEcxCU0m2r/4rrlala1dDs45TnqhCUb9OK2kzKVfGhfnNR K65vZdBRd1ZQy64rLA6okTDqnZJlg4iEcKWl3vPvHpEF9cYDl14R/L/hF3Gl+24Xa6zH 2jKa4PZ+GBZVUI2SgaGXek+SIQxLUTuAwfJwr7HNxgf7dL9lq2HsSCoEq0E9N3X874lG bgFkXnolQqNknRLss7UDiGiK/2UpeS96//MJ1QmzwPEH5C2S/4sa3lMXWBag3ZFyemv8 HxhA== X-Gm-Message-State: ACrzQf1iresDChF6yza+pbvB3z1Zo4o8/s9KjWdJe4TOlodVKOlMjA+T wrl2H2UGm5SLhMJZ2CKlPS6ZmMOyx2jUOg== X-Google-Smtp-Source: AMsMyM7f4Puu3BTHJwbvTJTYtmemHJ1wNoy5QWOuaQqEgBaVhmgLQUOc9N0DbG4VzFPjwKLzqLIIgA== X-Received: by 2002:a17:907:728a:b0:78d:2b4b:e7f7 with SMTP id dt10-20020a170907728a00b0078d2b4be7f7mr2527309ejc.269.1664973129511; Wed, 05 Oct 2022 05:32:09 -0700 (PDT) Received: from Mini.fritz.box (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id n19-20020aa7c693000000b00458a03203b1sm3778734edq.31.2022.10.05.05.32.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 05:32:08 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Po Lu Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <87lepuv5l8.fsf@yahoo.com> (Po Lu's message of "Wed, 05 Oct 2022 20:05:07 +0800") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <87y1tuv851.fsf@yahoo.com> <87lepuv5l8.fsf@yahoo.com> Date: Wed, 05 Oct 2022 14:32:07 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: > Gerd M=C3=B6llmann writes: > >> Po Lu writes: >> >>> I'm going to guess that window_sub_list is returning a window that was >>> not marked during GC. It's a problem that also exists with my >>> incremental garbage collector. Does this help? >>> >>> diff --git a/src/alloc.c b/src/alloc.c >>> index 419c5e558b..522925d248 100644 >>> --- a/src/alloc.c >>> +++ b/src/alloc.c >>> @@ -6634,6 +6634,9 @@ mark_window (struct Lisp_Vector *ptr) >>> mark_glyph_matrix (w->desired_matrix); >>> } >>>=20=20 >>> + if (w->next) >>> + mark_window (w->next); >>> + >>> /* Filter out killed buffers from both buffer lists >>> in attempt to help GC to reclaim killed buffers faster. >>> We can do it elsewhere for live windows, but this is the >> >> Indeed, that seems to work! > > Could you please replace that code with: > > if (!NILP (w->next) > && !vectorlike_marked_p (&XWINDOW (w->next)->header)) > emacs_abort (); > > And see if Emacs ever aborts? > > I just remembered that the old garbage collector does not work the same > way as the one in my branch, so that bug shouldn't be possible. With the change diff --git a/src/alloc.c b/src/alloc.c index 419c5e558b..4e0dd12729 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -6625,6 +6625,15 @@ mark_window (struct Lisp_Vector *ptr) =20 mark_vectorlike (&ptr->header); =20 +#if 1 + if (!NILP (w->next) + && !vectorlike_marked_p (&XWINDOW (w->next)->header)) + emacs_abort (); +#else + if (!NILP (w->next)) + mark_object (w->next); +#endif + /* Mark glyph matrices, if any. Marking window matrices is sufficient because frame matrices use the same glyph memory. */ I don't get an abort, but the ASAN error again =3D=3D67682=3D=3DERROR: AddressSanitizer: heap-use-after-free on address 0x= 000107130d00 at pc 0x0001002a481c bp 0x00016fdcc3c0 sp 0x00016fdcc3b8 READ of size 8 at 0x000107130d00 thread T0 #0 0x1002a4818 in PSEUDOVECTORP lisp.h:1110 #1 0x1002a4888 in SYMBOL_WITH_POS_P lisp.h:1122 #2 0x10025a338 in EQ lisp.h:1342 #3 0x100280eb0 in run_window_change_functions window.c:3964 #4 0x1000f18c4 in redisplay_internal xdisp.c:16600 #5 0x100107bf8 in redisplay xdisp.c:16111 #6 0x10089364c in -[EmacsView layoutSublayersOfLayer:] nsterm.m:8661 #7 0x1900a9624 in CA::Layer::layout_if_needed(CA::Transaction*)+0x224 (= QuartzCore:arm64e+0x20624) #8 0x1901f661c in CA::Context::commit_transaction(CA::Transaction*, double, double*)+0x1c0 (QuartzCore:arm6 frame #8: 0x0000000100280eb4 emacs`run_window_change_functions at window.c:= 3964:7 3961 (de-)selected as its frame's or the globally selected 3962 window. */ 3963 if (((frame_selected_change -> 3964 && (EQ (window, old_selected_window) 3965 || EQ (window, selected_window))) 3966 || (frame_selected_window_change 3967 && (EQ (window, FRAME_OLD_SELECTED_WINDOW (f)) (lldb) p window (Lisp_Object) $18 =3D 0x00000001071c2935 (struct window *) $23 =3D 0x000000= 01071c2930 (lldb) p old_selected_window (Lisp_Object) $24 =3D 0x0000000107130d05 (struct Lisp_Vector *) $28 =3D 0x0= 000000107130d00 old_selected_window looks strange. It's a global that is not staticpro'd \o/ From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 08:38:33 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 12:38:34 +0000 Received: from localhost ([127.0.0.1]:56177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og3fV-0002rY-Nh for submit@debbugs.gnu.org; Wed, 05 Oct 2022 08:38:33 -0400 Received: from mail-ed1-f41.google.com ([209.85.208.41]:45598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og3fT-0002rL-Rm for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 08:38:32 -0400 Received: by mail-ed1-f41.google.com with SMTP id m3so22763027eda.12 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 05:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=QpX4niQuok0nBdLasClanXJIpKIM8XBwhoJgaF+QTNM=; b=ZNkHR4CSrAisWHJfjbdZ2tdPL7ZLMNKowDYT0c8kea1cdgZBs+kPdl6aZnGLsEUpn1 rRhXTDPgUJocskl3Kj1SBTExPfe3gXJWaRt8utRHeG6f9Tah51ht+gfEUb7T33TvjdPW DA2GR5qLumxvqJD9Qt4zKsAyj6w4rlDUMoQ29E38hmGFH+9TJF5PLa7/Z0nCQPVU+zzo SdGIi/wsKnRJ0phnGTq9ae9bMMyY2z6DuBkoZmh7jTxCwZmVTUWdMKh6wAxcvpekF4AS IRRnqzyNUd45J0xNbXeAPGXHcQYB3fjBzcu22KugEV8MXWCpU5mwp8tNxb5+BDFD22SH Jriw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=QpX4niQuok0nBdLasClanXJIpKIM8XBwhoJgaF+QTNM=; b=H+ClPBKuTfKdT3BmU0cL7Gy+4t/EaD8OyQcRZ8VUYAGcT3BgwkSAdA+6Vyxtl+WMi6 gU1o92cG0/eWwS9eDNVxM0bx+s6BhKbSu0Ax/oq427KbPVSuasSrq9jecBAATOEIvTw9 SDpI1fYB3GPslHrR6j0QwfcgVb+NZt0a2oQKX32gsk0gMmlQy6wn7CuAwrec9+qxHNYC 406BHYUdJA5QJNU9t2QwNERXI0r5QzSTebYlAdtrf2RwhqIEB+s/ZnTzzMP36/wH/5n4 Cg9Ajumim2l/T3V4RPo7NYc/+C5tXbXzq3N1F1dplm0VHwzO8IL6h9HEkjccyL/iQ4GK cu1A== X-Gm-Message-State: ACrzQf1mm6rGGW46nr44NqV7Tx4UlKoXnB0VXgkdInR2AQs1rBT3q8ek QG8cn5nSGhf1vC9K2TlMcNk= X-Google-Smtp-Source: AMsMyM7ERL0us0vgZ9Y/YvxZnQUhkyNJxvpxKCzhqLlUmsGXa3PTHZ0AMYnOXj1YucGf1A4i/aqiVg== X-Received: by 2002:aa7:de9a:0:b0:44d:8191:44c5 with SMTP id j26-20020aa7de9a000000b0044d819144c5mr28002059edv.232.1664973505989; Wed, 05 Oct 2022 05:38:25 -0700 (PDT) Received: from Mini.fritz.box (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id b17-20020a1709063cb100b0077077c62cadsm8640421ejh.31.2022.10.05.05.38.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 05:38:25 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Po Lu Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Wed, 05 Oct 2022 14:32:07 +0200") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <87y1tuv851.fsf@yahoo.com> <87lepuv5l8.fsf@yahoo.com> Date: Wed, 05 Oct 2022 14:38:24 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > old_selected_window looks strange. It's a global that is not > staticpro'd And with this it works again: diff --git a/src/window.c b/src/window.c index 12a212a85a..da80fabe33 100644 --- a/src/window.c +++ b/src/window.c @@ -8213,6 +8213,8 @@ init_window_once (void) =20 minibuf_selected_window =3D Qnil; staticpro (&minibuf_selected_window); + old_selected_window =3D Qnil; + staticpro (&old_selected_window); =20 pdumper_do_now_and_after_late_load (init_window_once_for_pdumper); } From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 08:48:48 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 12:48:48 +0000 Received: from localhost ([127.0.0.1]:56187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og3pQ-00038V-C8 for submit@debbugs.gnu.org; Wed, 05 Oct 2022 08:48:48 -0400 Received: from sonic317-34.consmr.mail.ne1.yahoo.com ([66.163.184.45]:34297) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og3pL-00038F-IQ for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 08:48:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664974117; bh=Jc0aEB4iQoT8kNFrub6O5BsycigA725bmpXNJbsd+uA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=mlraUXqlAD+j6C5+npgjbhX7nZuOEglR8c+FDU05kcc+BdNn0GxnmDyTm7YZ3FaovBK0ZFEbgz2QhmqpUuQr2lDKAp1JXqHQZ7f/8My7CS7y9d1SeUELhtpYDpmI/1luZG2KFJeB8nnLCNajE2Z/kxLWY5fH/ta9zJY1Ha4YBJNWmQw+OiP6mx1Ih6CpW5iKKJuoDvPFajCOs5+USBfczO22htrd1M46lo5vGeZOqwrFEy3M7deYUBxLvCCJHi5kUdvfxymPtpUkD6vZr4qFPrQCBcZ4zepoL2XTzylIirVI2Q4/IKW7PUKJxoSQnvSKDjCB2uekKo8fQXnwSZxzqw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664974117; bh=9RZHknQH1unP40tVTk7y4dtpFsx3Lj70zFK5Vdjkrl1=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=XcyMtJcDP11wSa14uIKbCeuEnZBjaXqMaFm1a2hZXCupCCdKMaUmtzLJzWBnK92MILMYZe9Ct5fG0zIZjglg9Vi3ddR+Byl5s/HlVnKQquC2LAsr4JGsobWTiZJI1HvS/59SQkWTb6PWZdXKlalCptr7erex4nn0DJzRj8fcki/9fCTtxDdkIDG7DLcKp631/Cjpv3ybolkIz3xyFYFyXOltWaekT/W8s8UdcrTJVG4wLQcHuG+C+acDRf7V5xTuUl+wZPeNHxhe24/bTxIkWwTqBqQNIKEZnDEsCPxjoVckntfjxBRdRSj5+yDfFOq1yYBlykQMUWdBvZAJnswxzg== X-YMail-OSG: FWVnQGAVM1l8o5WWiuE6QGo0ewTfFnkkTQGxUTxg8MknrBGi2tx62OTGDiRD2Vr kYoR5tebuj7N7GLCGtWYw3MaV_VINRWi45c4CGeZ5ZXPq_0GVAJqdHZSFbfZpyI9ru95dMzzDlLz TLEqaJVCdPP71bnHl8rc6GtP_Y6w4VhYDjv9x7liRFL_L5noGnDon0zqqBJuGqwj3UFmQ._n7vze 1W.BSC2RGQollFtkJExRMUFcJccuaswu_mDIwKGqEBTP6cKSJyF.UH_aND1.5zPnYSB188rOeIeI QVLyGrzguwbOrqOKBroEwoQQnW0Eu7hvNEXTDXprBQRkjpUSIDdQU.Au5IkmI.3rmAQ97K9YBUHl NDYyrGV3ADW5JM5TDYDcRRVRJ5XjAH2jp_.9_GptP9eFE4CCHB5tr87fEmMp8N9tsCgqqr_nblCd 5T.aoQT_QyDbS9F9FhKk9NrtgVzU92r50qmwX0U96VatJMpT6f7DSjweY5jIyausaforTfG.WuxH tkZgKq9IcPDg87nb0i9y0eDKwLK3KNW0wwmhSNThpLo.rU3wY2urJHTb6T2GmcErUNam1Pv9rWpo e13hTlgGIo7RTqecknrGGE.JigEWld5fvvzHCY0ot9531btHKPcZC9WtXMLfMC2l0DUXuU0Wpqr8 VZ05MJJyzD6wnon8._PEAz2ZA1ROo7XP2.TwimxOSA50Jiq43tIijsUWvudcz717iRwfNh4k13DQ 9QWS48NWMEmKXKWNJg1yP7m2AbsG1t3ShP4KPlm0ZOYbvPKEt5qVOiaPD53ZDfVVz.uODR1Vcg0a UGeqXmM3oHU.y5GS549zUOI7MVM.76n6b8NnEksriiIpakNPs3QI_jfsxqAXIsan1Mv1xU_N.IjM H8454nWLJeJFDniYIq2CVleWUkGGjqP7opGkQnBhQmD14oVh1GhcD3Zp3zEJD_Qd0bPfxyE97Gby 0lS2DH3HYaKU34MSBu.1jmDkXmF2vZW9JHDDA3QLGSpwWVJ2jeehreu8ogaO_jbYcwFPOfeGus.3 CvSrokg6TsEj5F3OakTPi1l4n9.jnOn0HyRx7vNpqZ_aNjEP9g1oI_AVk0UXUlhxcYxcJSgpZaRQ wV6XKKCPBdncQDoJbFmChcRcvDfXZae7UsE4D2Oi2SL1OIaFe46vAQHb8ldnTEaQKZlPyAIkbz9K 76TDIBqXdgzCVXhv0w5HlhCdrloVlqHAuSLy972rFFr3Iks.KQcUkm6Un4g0QVE5ah6ZvYokxQrf 9jE8sQc0qrfYjzd2CclqmIzcjnyuK66lykPx1xEPUvv1Q0ICbt2IqrgquNbhsQ8rlIRe2HTlQlTN hvolku4Hg8Lp.P7v7mdIENWAt822T8AJaMlmML34TPOFd1tVj6anIRtJ42oFomYyXt9tfA.ga7HK Q0fliA1M4VRQOJBXJVv6HFrrAabzjEKhqWUZBy54wCEG6ldk_ZLdx6qArWwedIQgkqCet6SDdRbA kY1Rpe82ngkF3EI4uIHBhoWf_GKiJY1qhHREyQ.L8n2vHl0MmgSZF88ZE0Ak6ZSA1hucgkUUJY7o hjohUPH_pAnY5ptLZJWG32UrJxbou8TNf8OQj55KTOSUELoQlDBStudCCPTT3JQ7n4ogBchIKOcH jQtgkrOMl.IfhaVWJ1nEzEEz9RVUu0hGc0foVCm_ruEhXkRh6535_2EKGrm42ohbBA9s8PtC_BVL k.XCiJ1Ghzdxp42ONf1tkA.4fhAh.ZJS6MONNpgvw5L7yeqVh_tQnT0U9Ru8CfiVhNIlEpLdAahe KkiEtchT.Rkq2B4RyPUjEx5U5EZdKTq7JoJIFyEyhMnKVcKmsAtM3e6JWslrcjsY0IQcSb8C4acl 8z4LxJIgT4Wt9QKAPzUpMuItSmBvZGZej9h7u_71h5gnz7OXywnLPy.VonTuYjS1Qm7qK0VwIop1 iGclzZnV21W6x_kTl0AdAPDeEdUoUKFHnZNaLAsNO4OFdQJ68WOdJD9yuxw06FmLxqCkQw2dr.sP eCbsJvk5k9aOTcYfX1ucx1mhk9.Ftda1fNTaOFp0OtuWQhMEogWscwdNR0bXnlp1OljCFOaLwGI4 VOF5S.5B0LrVCRYWuy1W6BU7a9I1quEw98Kj7H04LDgbAbK_7XbxpBuZO9sKfDGe83Bzc4KR6GVw jLqybsOjqVm4gs9V3f_VlXqP8aUiNMcg99qWbBNJcv.zy3AEUWBGJQG39PaI9PU0PIrkev72trBG atH3svenEipnbjbAxfDlreEvM2CRKh5MfX1MgapUlrDd2_pg0UUVjrcSjzGHvqrT5_oKerHe4.ps - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Oct 2022 12:48:37 +0000 Received: by hermes--production-sg3-cf9dc7f8d-lcfnp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b3d28525a8c76a40a942a2bef978a1eb; Wed, 05 Oct 2022 12:48:30 +0000 (UTC) From: Po Lu To: Gerd =?utf-8?Q?M=C3=B6llmann?= Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <87y1tuv851.fsf@yahoo.com> <87lepuv5l8.fsf@yahoo.com> Date: Wed, 05 Oct 2022 20:48:25 +0800 In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Wed, 05 Oct 2022 14:32:07 +0200") Message-ID: <87czb6v3l2.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20702 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1916 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > I don't get an abort, but the ASAN error again Interesting. > =3D=3D67682=3D=3DERROR: AddressSanitizer: heap-use-after-free on address = 0x000107130d00 at pc 0x0001002a481c bp 0x00016fdcc3c0 sp 0x00016fdcc3b8 > READ of size 8 at 0x000107130d00 thread T0 > #0 0x1002a4818 in PSEUDOVECTORP lisp.h:1110 > #1 0x1002a4888 in SYMBOL_WITH_POS_P lisp.h:1122 > #2 0x10025a338 in EQ lisp.h:1342 > #3 0x100280eb0 in run_window_change_functions window.c:3964 > #4 0x1000f18c4 in redisplay_internal xdisp.c:16600 > #5 0x100107bf8 in redisplay xdisp.c:16111 > #6 0x10089364c in -[EmacsView layoutSublayersOfLayer:] nsterm.m:8661 > #7 0x1900a9624 in CA::Layer::layout_if_needed(CA::Transaction*)+0x224= (QuartzCore:arm64e+0x20624) > #8 0x1901f661c in CA::Context::commit_transaction(CA::Transaction*, > double, double*)+0x1c0 (QuartzCore:arm6 > > frame #8: 0x0000000100280eb4 emacs`run_window_change_functions at window.= c:3964:7 > 3961 (de-)selected as its frame's or the globally selected > 3962 window. */ > 3963 if (((frame_selected_change > -> 3964 && (EQ (window, old_selected_window) > 3965 || EQ (window, selected_window))) > 3966 || (frame_selected_window_change > 3967 && (EQ (window, FRAME_OLD_SELECTED_WINDOW (f)) > > (lldb) p window > (Lisp_Object) $18 =3D 0x00000001071c2935 (struct window *) $23 =3D 0x0000= 0001071c2930 > (lldb) p old_selected_window > (Lisp_Object) $24 =3D 0x0000000107130d05 (struct Lisp_Vector *) $28 =3D 0= x0000000107130d00 > > old_selected_window looks strange. It's a global that is not > staticpro'd Isn't old_selected_window supposed to be kept in sync with FRAME_OLD_SELECTED_WINDOW in old_selected_frame, with the latter being removed once it is deleted? Would someone who knows the window code well please take a look at this? From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 08:49:30 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 12:49:30 +0000 Received: from localhost ([127.0.0.1]:56192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og3q5-00039n-QQ for submit@debbugs.gnu.org; Wed, 05 Oct 2022 08:49:30 -0400 Received: from sonic317-34.consmr.mail.ne1.yahoo.com ([66.163.184.45]:39738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og3q3-00039a-H9 for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 08:49:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664974162; bh=xh+8REQqA3BNr0wzwGgnGHpOPESJ4JVwWchl9ohvRa8=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=r0A0K+rI3zCdnoWFFremVHPYNFzwWiBf875ejtrSidL+ntMqOdVnL4tuiWuhNY0mF/GYyK2OAMMivKJzT9iKrpZ21ND74QTmY9KVqifFUXnKLDll1e1hSMThTYLLl+//vFvOxi/Ogbm20z7UAsG9njfTfMybFqr7eqhjEIhF4m1jLTOCU/LrQmJdeSyRmERSkYeGlcglzc8oh3V+KRHdZLz7rYXntJw+MiQ1seZEADkH+aDMe/cKNCiS4vymx3Zkln9aqW6sixCzXOF4zLID57qoc2ax+qwAS2SoGN+D+ZIvOsQr+eYcUBnLbBYDUw0pVZa1LgWXVvohFWstRCSphQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664974162; bh=MoasVmqrtlItvLEE+sr3HxD3WWBt+8lVMebGHrumMBg=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=rfO91E4ia84QMj4lklaG4TrHugk4eHXi/7SIqaz1JZgO1SmuPHvK0m5Yihj4HDRLrDizqCUYdmuALO3K81w7F8VEJi9jmhvYfIOpMeqZCaUmwXH6NH54WFCtrH1w8+jKmk7gsUP7QEHP1QjUBoDE/wcYfgGa9L82dfPVdfoV4yR5ePFB8OqRZDBW6APIYM9NLQ2hXrU70G45EkQvEMkjCeg9uYjxv0ia66Bj0lVDlpRtDQupLaw3K4gmajKxIxxjPGFaMor3w006VB1gypiW1x0LgY4D/snTiFaFRAUGfuZD2yidiaa0rAw6zKoSMkFNwSd+tzOFv40wOKSx66PpHw== X-YMail-OSG: 11fvpkAVM1l7o0jKgRLZUZGG3_4QqbWQZsr.sDXJgtwOZ2nKQpKs94yxIjrngAp cWiFsdUWiUPWIcGl.Iq8ZbQWbZBBrnkuoEzyYkh9Qhnkjxn_u.IMH6HTNC2M4V4HTF2Borqlf9fz NCKchNkNzCdVRXVpsgnNEA9P5QD8Cct8pm1Vb6xYXT78kkptovT1yiCmNQrhuyGU322gMh_HBVJt iYNfTItWeVJF0NSND25FpT.1jaY88fvZHvqks3oSL9tbI.VH1_brJ8mzOHx56wPMjLsZ2XtIPHLQ aqtyne83LTDjDJ3nEzf7Nz6szzGU7b8uPeLJ.9Hv.urogG5q_C8P97EydFV3vGyXYcC5aJznE.t9 lqeEU72j4wKX.yZxdXMsv_GMhsG1_K.sv4mmn8I_VL4VVnMu8Tnw00v11Gr4iHtrQyOT_.1DYZy6 BgfI7gubdIO5xL6SyUCvyEKp8L8HMGxDSldGn0AQwvcd4MHR5v4AA73VYv1PnL15hchujrD1XOrs ElqdyPN8oSaJU2RrHM_DUGEPJrT9ONl2K6eOPrj32VaLGPl5lyTmbzEoeC.DcofXwtMqmUlE1agl kccJK5H2A9H7g5htkNgMVauzhhqV._ZQo1.lf4e5C4gABtfoacKffi1f1gpWEwjCnbU63HsOPDc1 x0Ex6PeGt3jM9vRWrBqqFvkI6ZtNgmibiCLoQewYbu1j3QQplcFQmYHrMbmPbMKUCVYoAdm0mFUH 2suo6m09V0wrbQXJTPofETkA9PDbqpRySG9GxZz54caEfMYUWDOndXrXPTXimucNsajtzcw6SLqb 1WaWusSe7BP4ZmDLrRVOvzdvW0SLPjVkIFKhn7FQ3I8DVP8SceXsFfsaKprSGF9_fey83_YbrvoA SPqZCvVErgYcL0WRztqTg.iRAz6Px4U6YV0n2oP0YxzW5_pkwpObHllqUbykC_N5sMGfJ.ucsMa5 DsS8R2w3Cp79Y46laSe4dPAaJUvPQeFsDQjOCf20gM14iLrQ3vzNrDXG.QNJvSi.LWP57zDWinvx mTh1IR1sgmr_RlZgxsCGjBVVcQE3CIooswsK68U5wvX8dFDfV.1dUrRayZ0AFu6NlS2XU1VD19KC Mr9ukIqtAR2v.r6W_Jgq767P7eFeAzZglKPW9oxGOQF1hvfBn9qR7HM0tP6_ouGUugXuRqiAYWzj 0EhG_Ju9HKq97doxoTzyY8kQgjZQCt_QXclhf.Ciqe8O5jZDdQki2rNhB95JRSgVVPVmP8x5aEVe sTvuehhuFUfR88OnGovf.9jcb4HFLxmXcJmdOQ5qCkEEZtZopMgq1O41AJan21WDt2rs099GYg2d ccMGV1nUR4m4vtlE9l8IksKlLuEoY3k2S2wlb1lNDi7lwIkJHCUlqpoXQOUcdtx8qc9RbAEG_jLw _hW5WDO4QCb5xkUVdtcb3Z.ozbwKZLEQZSsIxwJo6j003BMcjve11SKel.6pSHBfWpBNH3F5LFuP S4OL3IDlSeruhp54BgKUloerWAEzaevCDf.oiXJ7LkjS2Ji0OxqZCcdEHXmoElt7tXHg7zcax922 yV0q4i2c.5JyeovgUi4l.dsNh.Pd16WA5nn28FoIfdbS5XxCiE91Jwlw1Fp8wBhBX_Bh9AwdJxE. IgExk4Qt0yXo8wJ4hXxhuA8SrZ.VdhRs0GvB9pEt3rWvwshEVTG4hFDrgCntTMOx28Dvd0pBIQ5j HdtBndP54PWL4YIR64i9JPG5Jm0DXTOXy9FHDF6OQnEC_nhB_hRGG7G3G5h2ASWH2Cbm4z98oXmN zUaqtcl_qBTnM20O3bUoSZRHGKARs1qKPRQVHamJT2rAgZGjAu8Ckj8pqKrh1ZdEulUiyatdiOPn 4FB4WaJfbimLlEEEqDMyeUB760IOmz3sEnUphqieMD4xe63X.1wG4.L7_QuB.idhOU7oBoP3Oqxu rD.wYcXVK9W1.UVwk7hnic1i0pnmFtzhjseeuzwrigRw9yYY.uUNknw2sbpbHiVmR1JILUP5gT2m .7PPmcW.iLJ1bUE9w1687WWyu4LctWoN1HOA74M8vV0Z42ZpgJjA0kcMVBSMpR24lrH166YlEzm. 0i5dCeFwJIw20XS8xCF7Eis1RNpWJPB9m_LBGb2lppHLz1LjYEZjrdANGoY4BhF2e6HWglld6tIR Ugd3rVpRTnGHiWwqrom8SzRzvXGREvX9zgKlhoiiGNx1PUTexCc4rEkdMA0YrDHHCWxntwnXBMK3 W7OTxLaiQRZFS77l7_bem1zLc7OX857Wf5Kktpa1p3.t11fTFS.HoabchFFt.5Ia.YyGZcQoFMPs f X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Oct 2022 12:49:22 +0000 Received: by hermes--production-sg3-cf9dc7f8d-5h5f2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9097b6a6ce236bc9bea4f949f6419374; Wed, 05 Oct 2022 12:49:15 +0000 (UTC) From: Po Lu To: Gerd =?utf-8?Q?M=C3=B6llmann?= Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <87y1tuv851.fsf@yahoo.com> <87lepuv5l8.fsf@yahoo.com> Date: Wed, 05 Oct 2022 20:49:10 +0800 In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Wed, 05 Oct 2022 14:38:24 +0200") Message-ID: <878rluv3jt.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20702 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 615 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > And with this it works again: > > diff --git a/src/window.c b/src/window.c > index 12a212a85a..da80fabe33 100644 > --- a/src/window.c > +++ b/src/window.c > @@ -8213,6 +8213,8 @@ init_window_once (void) >=20=20 > minibuf_selected_window =3D Qnil; > staticpro (&minibuf_selected_window); > + old_selected_window =3D Qnil; > + staticpro (&old_selected_window); >=20=20 > pdumper_do_now_and_after_late_load (init_window_once_for_pdumper); > } Right, but please see what I said about old_selected_frame; I think it is intentionally not staticpro'd. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 08:59:47 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 12:59:47 +0000 Received: from localhost ([127.0.0.1]:56207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og403-0003Oj-GR for submit@debbugs.gnu.org; Wed, 05 Oct 2022 08:59:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og3zy-0003OT-Es for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 08:59:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54974) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og3zs-0005dC-7T; Wed, 05 Oct 2022 08:59:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=NHNypw5u8jRKkvEFzXgOZnmhpGLvNscuv5P4r4k78+0=; b=BGNLKyFcK8KT+SlOHes8 c/GQf0uNfQFk7u0CZaartWFlHazvKZjBDdHXkb/g1vzaTqALiB95JPWhBYz7uVTbbvjw0pTSLe/Lo RoGtgpDOKplK9HwlenNCORkvdGTflkVVEwR/F4kdwF+inJvjglBnFB4V8eoVxry3tVEJxwsfLPR7C 5f472+Fvope2ACq5qjwKddyIoeYtlZZcTeq+taJ5dyyzJHyGxsLAu+lO3ACFp+9hG1X7ZG1MWHw5M FPmemDbCc2oMdK9m1J9nixD6ztRGblN3dNG1oENV6kNvn9efXL/GeQ8ngubR/DL1PrVJs/292hQYw mLJSE9eYOopmaw==; Received: from [87.69.77.57] (port=1347 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og3zr-00055S-Mf; Wed, 05 Oct 2022 08:59:36 -0400 Date: Wed, 05 Oct 2022 15:59:33 +0300 Message-Id: <83edvmtoi2.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?iso-8859-1?Q?M=F6llmann?= In-Reply-To: (message from Gerd =?iso-8859-1?Q?M=F6llmann?= on Wed, 05 Oct 2022 12:14:04 +0200) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: alan@idiocy.org, 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: 58042@debbugs.gnu.org, Alan Third > Date: Wed, 05 Oct 2022 12:14:04 +0200 > > Eli Zaretskii writes: > > > So I guess we should do this dance around calls to maybe_quit in > > regex-emacs.c: > > > > specpdl_ref gc_count = inhibit_garbage_collection (); > > maybe_quit (); > > unbind_to (gc_count, Qnil); > > > > Or maybe even better, do this inside probably_quit (because who knows > > how many other callers of maybe_quit could be hit by this unexpected > > GC)? > > > > Can you try this? > > Isn't the -[EmacsView layoutSublayersOfLayer:] the problem? AFAICT from > a web search, this is an event handler method that is also called from > by the framework? > > In the olden days, it was a serious error to call into Lisp from an > event handler. All bets were off when that happened, not only related > to GC. I believe that hasn't changed much. > > That code was introduced by Alan around this time. > > 1ba02d85a964e1b2c6a9735cd3decdc524e06dc1 > Author: Alan Third > AuthorDate: Sat Jun 12 10:25:47 2021 +0100 > Commit: Alan Third > CommitDate: Sat Jul 31 11:13:05 2021 +0100 > > Maybe Allen can say something, I've CC'd him. AFAIR, this was the best way Alan could fix display problems on macOS. He tried several other approaches, and all of them were worse. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 09:13:13 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 13:13:13 +0000 Received: from localhost ([127.0.0.1]:56238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4D3-0005wv-1M for submit@debbugs.gnu.org; Wed, 05 Oct 2022 09:13:13 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49206) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4D0-0005wf-2d for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 09:13:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52848) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og4Cu-0007y6-65; Wed, 05 Oct 2022 09:13:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=f2JdsM1huOMB6MzTTgGgTJztWotatewgQ4OG7ISziOU=; b=CeHG8Vnhvllwv2UG24cj c/DGRr9eXZV4bqjH9PBWeGNL1/1VL19NocQG2fu2eIFQhYfZb3UZlpbb/RKYIxcCRd/HiEArjZ+Qj 12RM+2KpdaVi2MNY5rxDZAhiMaCP5EJhGhOxP+F1k1u03iQ/Do+W+/wfDwcMUYYgXXKINz2Ep4mR0 UryFYtoXcKjQdd5NQ4tVB/s9+1wo6a4F+MKR3I/ajjLmHa0yOXskn0eAtebhA8xWsndRmhdFEtTOF +89X6qmovulkUVyu8BanD3VtizmrCJz1XOZxkYbyq2iVJA1xnToljo/h4YpCBwstRErHNFJb/fQk5 WumYm4nXflr9IA==; Received: from [87.69.77.57] (port=2168 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og4Ct-0007h8-7s; Wed, 05 Oct 2022 09:13:03 -0400 Date: Wed, 05 Oct 2022 16:13:01 +0300 Message-Id: <83czb6tnvm.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Wed, 05 Oct 2022 12:45:04 +0200) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: luangruo@yahoo.com, alan@idiocy.org, 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: Po Lu , Alan Third , > 58042@debbugs.gnu.org > Date: Wed, 05 Oct 2022 12:45:04 +0200 > > And an update to the second ASAN error that I could actually reproduce > by starting Emacs on my branch: > > ==64010==ERROR: AddressSanitizer: heap-use-after-free on address 0x000107130d00 at pc 0x0001002a48d8 bp 0x00016fdcaa80 sp 0x00016fdcaa78 > READ of size 8 at 0x000107130d00 thread T0 > #0 0x1002a48d4 in PSEUDOVECTORP lisp.h:1110 > #1 0x1002a4944 in SYMBOL_WITH_POS_P lisp.h:1122 > #2 0x10025a3f4 in EQ lisp.h:1342 > #3 0x100280f6c in run_window_change_functions window.c:3964 > #4 0x1000f1980 in redisplay_internal xdisp.c:16600 > #5 0x100107cb4 in redisplay xdisp.c:16111 > #6 0x10089364c in -[EmacsView layoutSublayersOfLayer:] nsterm.m:8661 > #7 0x1900a9624 in CA::Layer::layout_if_needed(CA::Transaction*)+0x224 (QuartzCore:arm64e+0x20624) > #8 0x1901f661c in CA::Context::commit_transaction(CA::Transaction*, double, double*)+0x1c0 (QuartzCore:arm64e+0x16d61c) > #9 0x19008b4c8 in CA::Transaction::commit()+0x2bc (QuartzCore:arm64e+0x24c8) > #10 0x18bee1698 in __62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke+0x12c (AppKit:arm64e+0x1ac698) > #11 0x18c646754 in ___NSRunLoopObserverCreateWithHandler_block_invoke+0x3c (AppKit:arm64e+0x911754) > #12 0x1892101a0 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__+0x20 (CoreFoundation:arm64e+0x841a0) > #13 0x18920fff0 in __CFRunLoopDoObservers+0x24c (CoreFoundation:arm64e+0x83ff0) > #14 0x18920f524 in __CFRunLoopRun+0x300 (CoreFoundation:arm64e+0x83524) > #15 0x18920ea80 in CFRunLoopRunSpecific+0x254 (CoreFoundation:arm64e+0x82a80) > #16 0x191e4e334 in RunCurrentEventLoopInMode+0x120 (HIToolbox:arm64e+0x32334) > #17 0x191e4dfc0 in ReceiveNextEventCommon+0x140 (HIToolbox:arm64e+0x31fc0) > #18 0x191e4de64 in _BlockUntilNextEventMatchingListInModeWithFilter+0x44 (HIToolbox:arm64e+0x31e64) > #19 0x18bd76518 in _DPSNextEvent+0x358 (AppKit:arm64e+0x41518) > #20 0x18bd74e10 in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+0x52c (AppKit:arm64e+0x3fe10) > #21 0x18bd66fdc in -[NSApplication run]+0x250 (AppKit:arm64e+0x31fdc) > #22 0x100870bb0 in -[EmacsApp run] nsterm.m:5799 > #23 0x1008c7b0c in ns_read_socket_1 nsterm.m:4679 > #24 0x1008ae530 in ns_read_socket nsterm.m:4697 > #25 0x100437168 in gobble_input keyboard.c:7379 > #26 0x1004389d0 in handle_async_input keyboard.c:7610 > #27 0x1004389b0 in process_pending_signals keyboard.c:7624 > #28 0x100438acc in unblock_input_to keyboard.c:7639 > #29 0x100432cac in unblock_input keyboard.c:7658 > #30 0x1005ba024 in garbage_collect alloc.c:6256 > #31 0x1005b950c in maybe_garbage_collect alloc.c:6090 > #32 0x10064f6a8 in maybe_gc lisp.h:5622 > #33 0x10063fcfc in eval_sub eval.c:2388 > #34 0x100640838 in eval_sub eval.c:2449 > #35 0x10064234c in Fprogn eval.c:436 > #36 0x100654eb8 in funcall_lambda eval.c:3218 > #37 0x1006532c4 in funcall_general eval.c:2941 > #38 0x100647fcc in Ffuncall eval.c:2979 > #39 0x100651ca8 in Fapply eval.c:2650 > #40 0x10063ead8 in apply1 eval.c:2866 > #41 0x1006484bc in Fmacroexpand eval.c:1149 > #42 0x10065394c in funcall_subr eval.c:3019 > #43 0x10072e004 in exec_byte_code bytecode.c:809 > #44 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 > #45 0x100654994 in funcall_lambda eval.c:3138 > #46 0x10065316c in funcall_general eval.c:2929 > #47 0x100647fcc in Ffuncall eval.c:2979 > #48 0x1006fcd80 in call2 lisp.h:3302 > #49 0x1006f4ecc in readevalloop_eager_expand_eval lread.c:2151 > #50 0x1006e0b0c in readevalloop lread.c:2343 > #51 0x1006e236c in Feval_buffer lread.c:2416 > #52 0x100653d24 in funcall_subr eval.c:3025 > #53 0x10072e004 in exec_byte_code bytecode.c:809 > #54 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 > #55 0x100654994 in funcall_lambda eval.c:3138 > #56 0x10065316c in funcall_general eval.c:2929 > #57 0x100647fcc in Ffuncall eval.c:2979 > #58 0x1006ddfe8 in call4 lisp.h:3317 > #59 0x1006d9058 in Fload lread.c:1483 > #60 0x1006e1158 in save_match_data_load lread.c:1636 > #61 0x10064e9c8 in load_with_autoload_queue eval.c:2271 > #62 0x10067cb40 in Frequire fns.c:3308 > #63 0x100653a54 in funcall_subr eval.c:3021 > #64 0x10072e004 in exec_byte_code bytecode.c:809 > #65 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 > #66 0x100654994 in funcall_lambda eval.c:3138 > #67 0x10065316c in funcall_general eval.c:2929 > #68 0x100647fcc in Ffuncall eval.c:2979 > #69 0x100651ca8 in Fapply eval.c:2650 > #70 0x100654414 in funcall_subr eval.c:3044 > #71 0x10072e004 in exec_byte_code bytecode.c:809 > #72 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 > #73 0x100654994 in funcall_lambda eval.c:3138 > #74 0x100650834 in apply_lambda eval.c:3088 > #75 0x100641734 in eval_sub eval.c:2529 > #76 0x1006f5394 in readevalloop_eager_expand_eval lread.c:2160 > #77 0x1006e0b0c in readevalloop lread.c:2343 > #78 0x1006e236c in Feval_buffer lread.c:2416 > #79 0x100653d24 in funcall_subr eval.c:3025 > #80 0x10072e004 in exec_byte_code bytecode.c:809 > #81 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 > #82 0x100654994 in funcall_lambda eval.c:3138 > #83 0x10065316c in funcall_general eval.c:2929 > #84 0x100647fcc in Ffuncall eval.c:2979 > #85 0x1006ddfe8 in call4 lisp.h:3317 > #86 0x1006d9058 in Fload lread.c:1483 > #87 0x1006410e8 in eval_sub eval.c:2496 > #88 0x10064234c in Fprogn eval.c:436 > #89 0x100646c90 in Flet eval.c:1023 > #90 0x1006403e0 in eval_sub eval.c:2435 > #91 0x10064234c in Fprogn eval.c:436 > #92 0x100654eb8 in funcall_lambda eval.c:3218 > #93 0x100650834 in apply_lambda eval.c:3088 > #94 0x100641c68 in eval_sub eval.c:2572 > #95 0x1006f5394 in readevalloop_eager_expand_eval lread.c:2160 > #96 0x1006e0b0c in readevalloop lread.c:2343 > #97 0x1006e236c in Feval_buffer lread.c:2416 > #98 0x100653d24 in funcall_subr eval.c:3025 > #99 0x10072e004 in exec_byte_code bytecode.c:809 > #100 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 > #101 0x100654994 in funcall_lambda eval.c:3138 > #102 0x10065316c in funcall_general eval.c:2929 > #103 0x100647fcc in Ffuncall eval.c:2979 > #104 0x1006ddfe8 in call4 lisp.h:3317 > #105 0x1006d9058 in Fload lread.c:1483 > #106 0x100653d24 in funcall_subr eval.c:3025 > #107 0x10072e004 in exec_byte_code bytecode.c:809 > #108 0x10065c16c in fetch_and_exec_byte_code eval.c:3066 > #109 0x100654994 in funcall_lambda eval.c:3138 > #110 0x100650834 in apply_lambda eval.c:3088 > #111 0x100641734 in eval_sub eval.c:2529 > #112 0x10064efb0 in Feval eval.c:2345 > #113 0x100451650 in top_level_2 keyboard.c:1141 > #114 0x10064a318 in internal_condition_case eval.c:1471 > #115 0x100451564 in top_level_1 keyboard.c:1149 > #116 0x100648aa4 in internal_catch eval.c:1194 > #117 0x100416f04 in command_loop keyboard.c:1109 > #118 0x100416994 in recursive_edit_1 keyboard.c:719 > #119 0x100417950 in Frecursive_edit keyboard.c:802 > #120 0x10040fb00 in main emacs.c:2515 > #121 0x101549088 in start+0x204 (dyld:arm64e+0x5088) > > That is redisplay during garbage_collect! > > The change to probably_quit didn't help. Commenting out the call to > redisplay in the layout stuff did. I don't think I understand what this diagnostics says. The backtrace tells us that Emacs performed GC, then called unblock_input, which called gobble_input, which on NS triggers redisplay. So far I see no problem; do you? Then redisplay called run_window_change_functions, which attempted to compare some window with old_selected_window, and one of these two (which one?) was found to be in freed heap memory? Why? because one of these two windows is not a live window anymore? So we should sprinkle more WINDOW_LIVE_P tests in that loop in run_window_change_functions? This has nothing per se to do with GC and with redisplay being run from the unblock_input, this can happen regardless of these. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 09:24:52 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 13:24:52 +0000 Received: from localhost ([127.0.0.1]:56252 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4OH-0006EO-SJ for submit@debbugs.gnu.org; Wed, 05 Oct 2022 09:24:52 -0400 Received: from mail-ed1-f42.google.com ([209.85.208.42]:33604) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4O1-0006Dv-Mo for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 09:24:48 -0400 Received: by mail-ed1-f42.google.com with SMTP id a13so23007565edj.0 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 06:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=93CRFstsuoAO8JPk0Ld0CsaO3AghBMZ0WdgrrHOC918=; b=b+Rfp3VkcHb8fllUazfuivLXYmsH3yEuX2A+KH8jxQtiG/uZcXInJRByagn/yBMPF4 6ZYyFZAqEr4ntls+YH7J0SyZ+jt1HILzstrnO/JS7n9qpxfu0wXbfANyOluUJnoRBkFt YwdBKSWOJgIahBXGzUFr41MiCoBQzVu3b4Cu28CDORWWqST9+uhjUYmrcLKRRtB5VDoF nMjHNaS4IhrMQWcDDLZL7YnPd2t27VDSWd0bmml6+TgUWAiyVrJUshZkr/jJAPjczMEo GOU37g2uoU+Jv3Gg1PO9+jWRGJh0UoZj1PCpuZecWLUR/u3gcimab3uZteP/3/qDsP++ 27PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=93CRFstsuoAO8JPk0Ld0CsaO3AghBMZ0WdgrrHOC918=; b=DQeMn45SS2QtCf4wqceB+Deh/daIVZDWt7owOsrzJ1DL/2c50399IRGhlKGpGJaqj9 okMQTp5Zx709LAwIcaAT/RAtFwz4Do3OUEL5Yu13knmAUiMEJzqdkujZ/oOjDItp4dd+ HnKxuC9euQpljGtPx/QgwFdZwz7DEJedMXWnnbYl36Jf/dunmC2d29UxePdHZr2xxe9z GJHXkCFy61xEwUrNckcx3KbT+TiY06bzmctl1WjYyMSy0ySBBDY1cAtOR9Nr49Z/4gMB aO/oX/+DnuPaThREx1v5EHwyMGYLMKkxwO592pmUO3Knp7YNzKPianl55EmQSXtJzku/ S4eg== X-Gm-Message-State: ACrzQf0dmLsTI3YMy6ul03LV0BsP2FLQuSv1fH4eY6yeMB8UcbjTb8v1 qRqJTE6WCZXMRyRGinpIJ30= X-Google-Smtp-Source: AMsMyM437Twy4zMS+VJRI6OCiRZEbLyO02UDD+xeY65iWiz9CiBx7MjxqdMhizgsGO6i3D11cceu6w== X-Received: by 2002:a05:6402:3584:b0:458:d3fa:fb89 with SMTP id y4-20020a056402358400b00458d3fafb89mr17552502edc.218.1664976267768; Wed, 05 Oct 2022 06:24:27 -0700 (PDT) Received: from [192.168.178.21] (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id k4-20020a170906158400b0073d87068042sm8643002ejd.110.2022.10.05.06.24.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Oct 2022 06:24:27 -0700 (PDT) Message-ID: Date: Wed, 5 Oct 2022 15:24:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal Content-Language: en-US To: Eli Zaretskii References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <83czb6tnvm.fsf@gnu.org> From: =?UTF-8?Q?Gerd_M=c3=b6llmann?= In-Reply-To: <83czb6tnvm.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 58042 Cc: luangruo@yahoo.com, alan@idiocy.org, 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) On 22-10-05 15:13 , Eli Zaretskii wrote: >>> >> That is redisplay during garbage_collect! >> >> The change to probably_quit didn't help. Commenting out the call to >> redisplay in the layout stuff did. > > This has nothing per se to do with GC and with redisplay being run > from the unblock_input, this can happen regardless of these. Right, this is a different problem. See later in the thread(s). From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 09:27:49 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 13:27:50 +0000 Received: from localhost ([127.0.0.1]:56261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4RB-0006Ib-Kx for submit@debbugs.gnu.org; Wed, 05 Oct 2022 09:27:49 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50820) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4R6-0006IK-Ai for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 09:27:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41092) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og4R0-0004aM-5x; Wed, 05 Oct 2022 09:27:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=VfsMaSRjXepb3NS74XYaj7J0DV414rOYTobpP2sWOic=; b=HO35xTcoThHtK/8UVI8a icNpSlrSvu7RpX5LfdGCRW1R5i2UpZiq9xom9naDzyN74/LkWhZFgAPJwl2hatpVZzvQ4AsAVgdXw wHYfmxILzBsmJviRX+0mRv6ntXcX/BSH8HNlY8QojYm1IKgFCaQgCy0O6DWRCWnpuL+QmRqKLm+hr FVobwU0fCGNTCPZNMU0LQetPDjWK0HK+FncHPVKanRwBoczMUUJ0BS2kTdcvf6DV7okF6lhu2TEQd dIl8kuZkQE7ULK+Yc6DlF4hxuCnIlYkdtC34DX+p6xt/hZayiuPRCKXnqE1z/gb4F1XMtWaRipjgq azzmekLDqpaZSg==; Received: from [87.69.77.57] (port=3054 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og4Qt-0001C6-RO; Wed, 05 Oct 2022 09:27:36 -0400 Date: Wed, 05 Oct 2022 16:27:27 +0300 Message-Id: <83a66atn7k.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?iso-8859-1?Q?M=F6llmann?= In-Reply-To: (message from Gerd =?iso-8859-1?Q?M=F6llmann?= on Wed, 05 Oct 2022 13:10:03 +0200) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <877d1ewnx0.fsf@yahoo.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: luangruo@yahoo.com, alan@idiocy.org, 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third > > Date: Wed, 05 Oct 2022 13:10:03 +0200 > > Can somone please help me understand how this works? > > Let's say we are in memq called for list L. Fmemq uses FOR_EACH_TAIL, > which can call maybe_quit, which executes arbitrary Lisp, which can > modify L. "Arbitrary Lisp" being redisplay that calls various hooks, like window-configuration-change-hook etc.? IOW, this is a macOS only thing? Perhaps on macOS probably_quit should bind inhibit_redisplay non-zero? I see no particular reason to trigger redisplay from maybe_quit. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 09:31:19 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 13:31:19 +0000 Received: from localhost ([127.0.0.1]:56266 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4UZ-0006Ov-79 for submit@debbugs.gnu.org; Wed, 05 Oct 2022 09:31:19 -0400 Received: from mail-ej1-f47.google.com ([209.85.218.47]:42608) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4UX-0006Oh-Pc for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 09:31:18 -0400 Received: by mail-ej1-f47.google.com with SMTP id kg6so20142801ejc.9 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 06:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=zt14wGPuA3/oiEQO7NOu4X98O4mT0grcGFoWbl7jjUQ=; b=iP14NqZpOLgt4P8XCA7heU0QgAwe7/CUbKSFd3bKD2YZew+2+VblWULAo0q7gPiTh5 AJgHffRiYLWqBdB3ySSu+LSYy/lwRerHR1nn7wTSmK0DTSxAHryIGOc1MPmRpCc5f5ew 88VOuSqsVcosJOUC++OKWHcTrQreX+pk5aIy1+Qn1jQG8t3VP7oLYiyooLy6m/dI2Xkk Ha0zeGMzgvnrEETgrbrX+9hSyx9qrg9tm+ahU0+iQ0zQnV5ktXwUPH2p1PxbWhvKX5p1 qxZ5Fnu1i9TBgai2Y7UtHUjVoOz6Ub8E/JavlifVqTzdXOToSJrjeRig+EHoJU9EssBJ CszA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=zt14wGPuA3/oiEQO7NOu4X98O4mT0grcGFoWbl7jjUQ=; b=5JoSFmwQ+th6sxPs3fKsEo7v2BIqnPt/k4aFKVi8BssATh+olilczBDhdHhJ/+u3HT Os/aKCH4m5mG1qqinW2gk0qR8XwV7xUZyCBymm2tOMYT84fzDgHvuyfM8Dd6neOml8fc xcBLWusNIiQ8ru3HDnyLxrcXisUwe9Jw1fSWU7WPsMy3zP33XGC96kpDsowbcnXOi+IH LN3pImTJ9/+hTk6kMpyE9VYXSe6PzIYP0VFCSe/By7qZ4gqZVmIZ+QbRhncHkB7/yEaU 9teyy8aAIE76utxHii1Yl8OTHKzxtkLmi9tRyx1xkoC/joB0ivK66VHBh7Lp75FKX2Ts 02lg== X-Gm-Message-State: ACrzQf0V9OD6+LYbjsDj0ri3kWpBie+2XKdpxKQrAHPnr68A4c3oLyMb fmLfXgHY56ADRSHeUtQJ4EhMHIl/b9dTZA== X-Google-Smtp-Source: AMsMyM4DYwa7mzwd7RmF86vAOSBM52OdnKPll8EUL1EN6zMOgsdWkkG2MFOL0bxDQRnyt2NcSNRrPw== X-Received: by 2002:a17:907:75c7:b0:779:bf7:9be7 with SMTP id jl7-20020a17090775c700b007790bf79be7mr23225493ejc.432.1664976672055; Wed, 05 Oct 2022 06:31:12 -0700 (PDT) Received: from [192.168.178.21] (pd9e36cc6.dip0.t-ipconnect.de. [217.227.108.198]) by smtp.gmail.com with ESMTPSA id y21-20020a1709064b1500b00722e50dab2csm8703463eju.109.2022.10.05.06.31.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Oct 2022 06:31:11 -0700 (PDT) Message-ID: <9e74f14e-cc2d-fa34-f9b3-5e0ebf500273@gmail.com> Date: Wed, 5 Oct 2022 15:31:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal Content-Language: en-US To: Eli Zaretskii References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <877d1ewnx0.fsf@yahoo.com> <83a66atn7k.fsf@gnu.org> From: =?UTF-8?Q?Gerd_M=c3=b6llmann?= In-Reply-To: <83a66atn7k.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 58042 Cc: luangruo@yahoo.com, alan@idiocy.org, 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) On 22-10-05 15:27 , Eli Zaretskii wrote: >> From: Gerd Möllmann >> Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third >> >> Date: Wed, 05 Oct 2022 13:10:03 +0200 >> >> Can somone please help me understand how this works? >> >> Let's say we are in memq called for list L. Fmemq uses FOR_EACH_TAIL, >> which can call maybe_quit, which executes arbitrary Lisp, which can >> modify L. > > "Arbitrary Lisp" being redisplay that calls various hooks, like > window-configuration-change-hook etc.? IOW, this is a macOS only > thing? I don't know. What Po Lu said sounded to me like it isn't specific to macOS (safe_call in event handlers, IIRC). From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 09:37:48 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 13:37:48 +0000 Received: from localhost ([127.0.0.1]:56288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4aq-0006Yg-K0 for submit@debbugs.gnu.org; Wed, 05 Oct 2022 09:37:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4ap-0006YR-1N for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 09:37:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48326) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og4ai-0006mM-Q4; Wed, 05 Oct 2022 09:37:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=IMpkrpVbb5w9g67Dk50KC7tpjNjRAxcqPtWC9gIKwok=; b=rGN1moLhwKQRNjaW2EDE xFqYm6pxJ8KpizwD+SB1EPGwWQyyEePo4MvWctjuVX8C5P6oQmyMao+jP1xqRd3byRmxE/1hx14Dv ktUhsQoSUqew7zeQz1sjaXKECHTY77erDQzALatvkoxuNlh/PG43i/guS/8Jl7WcIHgHsCZq/pwnJ mH6M/MkAnyqgLTRzfJM17/OhlRFZp6OfT/OPQsOLdxf4ykE6RbNdr7gOGRj0k+0SeS+sr5ou3HdOo JauDjVbnAVJZWBP+4Af56e6goJZkuOTJ3WgunfGV57yiS12v6pZ80Jda0yMCNlzDM89m2Y8HQr5N1 zuoY9Ltl+Gyxqw==; Received: from [87.69.77.57] (port=3670 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og4af-0007V9-TC; Wed, 05 Oct 2022 09:37:40 -0400 Date: Wed, 05 Oct 2022 16:37:35 +0300 Message-Id: <838rlutmqo.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <87tu4iv7w5.fsf@yahoo.com> (message from Po Lu on Wed, 05 Oct 2022 19:15:22 +0800) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <877d1ewnx0.fsf@yahoo.com> <87tu4iv7w5.fsf@yahoo.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: gerd.moellmann@gmail.com, alan@idiocy.org, 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third > > Date: Wed, 05 Oct 2022 19:15:22 +0800 > > Gerd Möllmann writes: > > > Can somone please help me understand how this works? > > > > Let's say we are in memq called for list L. Fmemq uses FOR_EACH_TAIL, > > which can call maybe_quit, which executes arbitrary Lisp, which can > > modify L. And probably similarly in another 100 places. > > > > I don't get it. > > AFAIU if it is particularly dangerous to modify L there, then input > should be blocked around Fmemq. How do you know whether it's "particularly dangerous"? We call maybe_quit in many places, basically anywhere where we have potentially long loops. It isn't just Fmemq. So if we want to prevent maybe_quit from indirectly calling arbitrary Lisp, we'd need to block_input inside probably_quit. Which means process_pending_signals will not call the read-socket hook and will not gobble input. That's bad, I think. And note that this is only problematic on macOS (AFAIU), because there the read-socket hook can trigger redisplay. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 09:39:51 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 13:39:51 +0000 Received: from localhost ([127.0.0.1]:56293 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4cp-0006bl-3G for submit@debbugs.gnu.org; Wed, 05 Oct 2022 09:39:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4cl-0006bW-HP for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 09:39:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36128) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og4cg-0006yY-9h; Wed, 05 Oct 2022 09:39:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ejtOhkQiv+OX4AH7JZq3edisP2SrHB6yOj9jfmvIsMM=; b=i4kN0ymd502i ENmxc/FFGBO2gMBQniwWKvt/uacFWOe8/kd7bNC9MHrFsc1W1h0sBg9efMsPY2OK61yQEmOg9NkkP ROYj7EOOGCs3Bsn20V5c6LRi1ovT0EsNB6AHzIZthhblut/qmDYVaRjNvr0s/jTBXFBOIKjwiVRy6 ztVS4pmGqHRb28w0l3j3IbTFQkX/YIRn/KqrqhH6owTaa+EJwKSKKJv0jPfHR5IU++H9HVde8GsFM z2IyF3UBlkZccPJGOO+BBplmhm5r/mFppOrqk/TV3n6Za3P5vjmu62zbb6H01ec8R69iRUS0l+gC+ oURGiuaj3qI9IJ/2jyKLMQ==; Received: from [87.69.77.57] (port=3797 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og4cf-0007fA-P9; Wed, 05 Oct 2022 09:39:42 -0400 Date: Wed, 05 Oct 2022 16:39:41 +0300 Message-Id: <837d1etmn6.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <87y1tuv851.fsf@yahoo.com> (message from Po Lu on Wed, 05 Oct 2022 19:10:02 +0800) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <87y1tuv851.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: gerd.moellmann@gmail.com, alan@idiocy.org, 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: Eli Zaretskii , Alan Third , > 58042@debbugs.gnu.org > Date: Wed, 05 Oct 2022 19:10:02 +0800 > > I'm going to guess that window_sub_list is returning a window that was > not marked during GC. Why wasn't it marked? From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 09:40:44 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 13:40:44 +0000 Received: from localhost ([127.0.0.1]:56317 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4dg-0006fB-5t for submit@debbugs.gnu.org; Wed, 05 Oct 2022 09:40:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48936) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4dd-0006ex-Nx for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 09:40:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34618) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og4dX-0007Gx-Lb; Wed, 05 Oct 2022 09:40:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=K87NWHbW78TGR6Ngubt3QIrswDZqsRdC0Qkz7QOAqRA=; b=X3/aRnjr+8oS 2AUaRe8mdCouOfUoyHlCYgzVROhPAzORPwv/1qi/ITiXfm2sJity+TTt0v+yfFsE5i73aVP6vdHCO GnSE68OOyiFKo6pRvifV/0gceOOWui1odXSY6G1/GJ8sgrvbRPJzjSROidkh9dahFAIBn6Clp8AEL 2VSGfKslhnNoXXA3oR2ltBb15rflAZEckNZOuTaSq3MGoCZU+vEhCAMVQHHqvw0rbk8U4B6XsOJKt j8RRMgCixNuBuzu9QsjrySnRktCULNkiDjAxBAOdrBiiRQ1xjgEuE9KwBxLr7IU6NsR/rAMDO4VS/ dx4y8sr1olsFlobLHC7IZA==; Received: from [87.69.77.57] (port=3850 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og4dW-0007nr-OR; Wed, 05 Oct 2022 09:40:35 -0400 Date: Wed, 05 Oct 2022 16:40:34 +0300 Message-Id: <835ygytmlp.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <87pmf6v7hy.fsf@yahoo.com> (message from Po Lu on Wed, 05 Oct 2022 19:23:53 +0800) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <87y1tuv851.fsf@yahoo.com> <87pmf6v7hy.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: gerd.moellmann@gmail.com, alan@idiocy.org, 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: Eli Zaretskii , Alan Third , > 58042@debbugs.gnu.org > Date: Wed, 05 Oct 2022 19:23:53 +0800 > > >> + if (w->next) > >> + mark_window (w->next); > >> + > >> /* Filter out killed buffers from both buffer lists > >> in attempt to help GC to reclaim killed buffers faster. > >> We can do it elsewhere for live windows, but this is the > > > > Indeed, that seems to work! > > Right. I've not had the time to investigate why unmarked windows remain > in the window tree Maybe those windows were deleted? From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 09:53:14 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 13:53:14 +0000 Received: from localhost ([127.0.0.1]:56345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4pm-0000js-1O for submit@debbugs.gnu.org; Wed, 05 Oct 2022 09:53:14 -0400 Received: from sonic315-20.consmr.mail.ne1.yahoo.com ([66.163.190.146]:38942) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4pi-0000je-RB for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 09:53:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664977983; bh=g0wFxmZ+TtTnkB4ANhhOtRYyH1OWFb1AABNja+1h5iM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=otsPB9fvMzsO07GPeHUjkG/Z3XIUw9g+qmlD5HSGb1X6eEixkgy0hduGsf8HbgcGSqeCPec28JUbdo5CgaYM9X2fR6FdFlSxf8FfyA2lmJ5MpMn+71TjpVVD7mxEWwDw+6PE4zbNnE0gtDMwLYLe01N/95v0NRNQuAm+L5O14CVus4rxJHaaeG4dQBVxZDhsQKX6IHkeKAkIX4xgxEaUg/zc/DlaP8B8AZiv6rzw0PfM80VM3YicnvWMBehyBNyGZ9KTUrD8wy7Dxda/TT9qo5MyFSIdwts+6+e49d4SFVCQoKGziilWf11t7xPHLOKHO7wpAjekL7kH/pinGnDltg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664977983; bh=ZvMjq8hZfTvskkvIrbfKJ2wQoABKGoBPNKaNm2FuvMt=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=gvOqPLDP6MdFoz03RQmilkhQfs7kfTW5QcAJWUtwmo6j2qNm2UdS4ANx24oNSvFkm9jatmu6PMrc6cBdHyMkIasuP9wGRJ17un/Ta1tioSW61/sIUy9GvbFynegqiTEuqAiw5mDqfRIZjoJvsPFoGn4+YOt8tPdL+Si0BhBK9HAERqshQWgBuw9u7/vl45KzCLq7pR4CHPxwpkn0qdOPuTYcIPj+5i1Iv36GEtsVINPib5qolkRtBq9Vlx27jpProqpmYTDMmRHxt6/4mBAyz1E6SVWRPeSpr1cWroOOAzMbT5eX3jrc2LgPxcThSLAI+fXZm3N3yq3htbV1U5O2CA== X-YMail-OSG: fXePB6IVM1mqeQ68wcrTrRdIuiCfdUKfnlKy0s1SiKflpdvVAG9fouSQ.JgmWLj rWWN2gZRbkPZmmEaLHUHIUb5N2BLJRN7W7iONwvqw74vqfXauk3JkmSPNOS057v2q3S529yKwRM5 lyer8MfatrrTCvSYzi0MS99TV6wyXdCSQZ2FVdQNX8DJH7asLG8IcVXQAuTzWbDz51OaOPnM70X3 h2wQaveMxmtL2o_C9BGuVD9eoKZyjERjk2kNA9a51PAJn3hxhbSsb23Y5IV9PulxvcAblNmsA9X7 B_Nxp_2YVNpWkgcBPzP3tsZM4pORm3WIR7t1V9AuBNhOH8Fl2j9ADJ4LZ9RD_KVnvDBl4xfs2IAD .XnlngyDm_6CVBPyqs8cMT0ZEpSrQcx24dzm1HeEtOXvPkgTM5BnLdIwzfm94HIO_hq2QKf.747R jkWWTzAw77IL2BP1CVY5BSESKPoVL_Ii0nxk5mOeV1.Q_LfqgNXs5HJjRnBLC_09s_KvuWvpZEo7 _8Gio1urxo1xAHnUuPeG3OVWb_qBisVdKN0EffX1jQ0d.vQtEDGeEJhnFzEaiYGlVRLxSHIk1D1N hr7suk0tCCccbb_qa0ZlFUGpcYQqFxAgxYZrJ4HBAFVnu.XenhVxZD.Bagl7y3W28EBDHXTVbaeK C_qDT7kghsYEyhYWSToFfo9RBw9Dbpc0s4t2cterqxw5ZdddOSZmhMPOM6uwccPSnevsvH_qqik4 rOWHzqtclcW0UJKSikVP2SJ4WId8uJOfVOs1uoUKh94xD8xbW.wx7PFBTd99avwFldhfOP043LT0 pJ0695koZDSAhTetzZE1deeB7MBnS0QXJmBqJx1kagOjs5XbLPfzrk_UCE_M4W4LA_JvUmsOv0Ui LJoXHNQqWgUeMEM3fHgyts2t5ojXbJ5cKAm7hQUHni_GQUtL8DyKd63yX6KHKzit.qasEXZ2osei kIESCuvxjU_ZH9OOICrCkfaqudd3ugtT7x7q96b285tINDUijUM14gCL_Wi_bSsfQAmAf8j..o.2 ENOYWk14D8e6L5ddA7iY7Oq2ur0SNCV6YyjBo4cQq3KTJjmmYWsnJ6nENfWz.14k.tQYCcrsYkg9 gKmi2anbr80WmWI2_p2ByjVUX.NL3REhQDE__u1GPSx23q88JH5Cy_vu0rkbyp5LQ381WoaUl_S6 gMTLwfEoogcOSKzQZO1SVRKOTjRNnjrTCSWZBwcr9C3jUKlYybblyoz5g.RX2O5qexIv7nA6nRj9 8GdfZG3N8BfiewSV_8v1DdS7ow9tLngo1TiUvcTqznj32kU5VZB1Cp3zVKECR3IpDdWwqXUZnWX7 TPa.JSWiUrh1B6q7LhNAQ5SzH6V7q43beU8AFvQWZKP0sjXoV0H.gY3sGxjMLrDAlmm7tZasAoup GUXyyIWd7.VJy4YzKyXsSwO.9Yu5KLNk7Dg8jJdC90OCLtDCnkuTmLCNyXSBhsU3QalLR8IULto4 dhmmy4UXFegO88Rk9XpRYIayP3zvGdfeAcFz9dQudE94BB6v_BY7ghcFIVe3rW5bcKX41bl2w7hN cAIMyaOef.W43sEiL.EkD9ehgdG9G.v7S.6kbBxnwsNMUsc0tLllshS6sxpjgj4Pgo6dDXCxGcae s_OJthByDoSYTngdo3oF2fHzoZ61M9zysQLDfwkl7DvvO5fT5rMGRAj9AJ6.mKzqfRQ9vxU.Yy9K B98qW0AiaJsmGkprdidCRr7KE94NZwTFhoEmDpHg4Wx2MNeavU5ZCFN7ZGyE6q3SmE1c3kTvBW4Y IFgpWhJa7OK8cTqPuN7n7AZZj0B6kcvMa9h2B2kCeEgvBRQW7kMyGQLh3xR_0sorbH2xU3Au7SLm 7MSHLPj4O8Rcu.Pfkp_YvzOpW_vUG85dhyhfJHuNJMOC5x9yvfjAKbPkq3SbyVprc_0Mh0uPW5sC IVbiTQdNn0gP8IN4zP_1Au5iNL8tGe60tO0.1y55OiW63LwNVbRgKSkqK2ytCTd5WizKy2jPETgC 0qsM7WP_Qy5YHKDgs_M1WjB26vxiqLpPqAGKW_BZbWpVAugoaalsv5RvLP0M70t9OWkKtEN2y5aH G2eFfyGBvATUUiM0sWili7M.tXzHFyCAvoRkDLazaLY6784VKSaBrKWVcpSerxsLxnKGdH0KkJ9n a9rDoXqB7UNDuZVVS7wXkNzdIcQo1eUQ.D5314pfi6t733pKBC4KfQHEkbd0iUBt9eGBCLpqLCXn KM5KmLPIRTtfBbJNNRZiBvn22xhN_ukh0x1kEyFBOK.z31eypVDwdvQlXcI0n3kF2C8naApvzpf_ c3sDM X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Oct 2022 13:53:03 +0000 Received: by hermes--production-sg3-cf9dc7f8d-tskmz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 393a6a4cb9a3be2d24eeafb1ec4eaf4f; Wed, 05 Oct 2022 13:53:01 +0000 (UTC) From: Po Lu To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <877d1ewnx0.fsf@yahoo.com> <87tu4iv7w5.fsf@yahoo.com> <838rlutmqo.fsf@gnu.org> Date: Wed, 05 Oct 2022 21:52:52 +0800 In-Reply-To: <838rlutmqo.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 05 Oct 2022 16:37:35 +0300") Message-ID: <871qrmv0ln.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20702 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 915 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: gerd.moellmann@gmail.com, alan@idiocy.org, 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > We call maybe_quit in many places, basically anywhere where we have > potentially long loops. It isn't just Fmemq. So if we want to > prevent maybe_quit from indirectly calling arbitrary Lisp, we'd need > to block_input inside probably_quit. Which means > process_pending_signals will not call the read-socket hook and will > not gobble input. That's bad, I think. > > And note that this is only problematic on macOS (AFAIU), because there > the read-socket hook can trigger redisplay. There are many different ways to trigger redisplay from the read-socket hook in the Haiku port as well, and I haven't seen any problems there. Besides, any call to automatic GC today can run arbitrary Lisp through finalizer functions, and that includes redisplay. So unless the read_socket_hook does not cons at all, there is no way to prevent probably_quit from running Lisp code. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 09:53:41 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 13:53:41 +0000 Received: from localhost ([127.0.0.1]:56349 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4qD-0000kc-Cy for submit@debbugs.gnu.org; Wed, 05 Oct 2022 09:53:41 -0400 Received: from sonic310-23.consmr.mail.ne1.yahoo.com ([66.163.186.204]:33641) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4qB-0000kM-Ds for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 09:53:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664978014; bh=Y/wBkj7w0MiEePnP0L8VUFs+0KdnQrR1ncQFz5O5qXc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=rXnjgS3Oso/Ype3jD2y09pDgwM/T8smZipivqgSG/kGOY7KY9d1MOni3Jq7q3HP68Y2zxGfHqLPJ+RKln3B5gmfakn0yKjHtfY0jT088LvoHKEofMrrU4sNO/kRuzhP8tdWgnVt/REnndN0T0w/rEvRLAPLO2mUBgBv3d9nt8DvQ3qCUsAHL/PXU/9vpe8LAjUN9TPT4WyhlOaZGnIKBIHKDGZTBhwhMiGIcXV6VpO+NLPEuvrNq7xKY/6VU9eht5HYw1tsGLWlc3aca9Ph5yenCHJFvJz9rce7ijRyR/9yE9GME4ZJWmdH3qDe1ZD+ST0tIZj+osKB1wApyReh3vw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664978014; bh=VrhryGfCQ9vosUUd8O/839JQPWnVRCuiDv5QH6aDzXH=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=md8bosPXilf4WtPA2FgRLNsOigL7+PUBvqr2nwPnzXtAgwRq//oED0MKGTaJ+ZqUmCwHKyXdloL0QUHr0KLqOYt+ws/283W6MNjTg23MxKYa+u/IEdMtHRxPsg+w7nO5eKXnmgvrPlmlXKTdJUV2DvoYCxnkBA0rDrrrQm5a7EL2FKgyJ34A1UsLKO8OOSfyCSYnVjCQPyGK4X46FR1ag3B+Qv+Ub5uVNx9J8KBmKxtFsHcZTZuhPrm62y9si4OtBvPy67y1SZX6YUqvmvJmJ7DKh/WV1hEFbz06l6oU5Pp22wbN4Be/0LqPwKLn193Eg8hrpvUpT+dRaWYGsD84aQ== X-YMail-OSG: DBOoW5EVM1m.keGVELBnG7CGLBRxcXYzk72DMrvOx3vMQdiQruBPyRR6cSKmU95 hyrgLTpR9nw2RllmTQPVtQ3Z707ogmM2ZDwZmMiOOXeHrbjcViWUlKwM6Qevf452_n5nIVEigdqm uRxYHucMGuH1AXgGU0HCKWtZBCmXq82UUrWa4JwYokH2kUO_OR9WjG13Jt52H2NYEyltFLKz2nf_ YKl5SkVgH3VtifJMuQcuCIBdNwG4sK6NnkWxd33HUeujsBaab4E1aP6CkzFHDvxadxU1Z8uzemYT 9YrFpqgzAYjH9PrxJy5wfDxC5QPouc8aqC7S5flX7j.DrE1nG5Q4czt1x9ZiPQ5aFIo_H8.WGqsE r2M70ec8ux.PAECVH_YBtRfOZWNZJuWu4eVyq3ruCG7sx4GnOP0Wbhjn_OJhqKtXozChReEixBHj 1v47I8pSP8zhr.ERRY9CnzuM7YkPqT2Ns0COK11cN08wf3GPIaQJcUI3.DMrZw_INQAtp99xNAac xycDJuQ5sw0vuvuxq.C._8unqpJ.pLN2MqytdGz9BXER1UYwpeyD9Ghh288DEvrrN.5sEGcXn37I lE3nWzUB.Ka06qbYG5W5Q_E0gNIRBlZcdqjghhctkGnYA61cDBXQ80TU8r9ZJ7_RUg1po1v4698c g4Ja8X9g04LlIZSNlzSqurTbHoKqUzsYxBIlLSuGkcAB9I4LarKjTsdEuwEjDTlXZ2BRhjW69A68 wmwlzDFv5WnFbxscW97bD_8QNarqo1t67oDRb.TLWwxa7RyQ3NVlcZNXg_XIH6MYm1japdahanZG s9qawgzA4ZHPQb3m6eQ7G3BHQyhaWyTuFEbkXDHBWr9b4PdjFbpj5HU9Ld5DClzNZIhsbXQYY6i4 XLl3dAQZqohQ8r_cYirxzXz3jDsfnXiU4athgRKBFimNkbtLJxVIG7riQaQNsbWKbEa3yasG7lJn rFbdY.UCS.WF3v4tGdt5U1_2y9Tt0fCnhWe_.ZXjij52kmAI6Q8mPWiRYx8rZubfKCSITIrLB5oB F7LaZieJT.S6ItJqPvzOKhmxBqdUk.xeiTVyffhemQJwU_bgPYF2idthg7eQ71OlvOtNx9aZ5X0u 0U8CZzyy78irZAKo1UFzGr82WIYV52ch1xw7cGmKfcLc4kMBNnSUM1Vkqzrwt_5bLD2hdUgHpnI2 _u6dSNV3aezPI.ODF3AD42.wA3LwR8TgXl0KGS_dekOrr.n0yMjMAmS3Kubq9Ci7Mid5OE1pevO. VEOgjvePiTHtaiBwJoO2OMs.7yN.FsKc89migOAB.EDyfMWKJgaZhoo_UsWtcA2FgYds28ohhsLR YoKSnM_fovEkQFxrcGTX6fnFhwETPzb.xqQ7hxOnK64btnTSmn_RfJ6RB6n8fMdjiUlg7lwSvXhF hjexyIvQps81HHKq6r6aIc5fi7BJ7QZB7zn5W1v_t8YfD1aHMZmFPABsqqcJ.9ODsn8MCBCG4HsT 24Z22j8Zj.6VYAPa5G3hNA6yNsuvk4bDk0OMUyAcPObmjpTUT._OnjGwcoo31hRZeYnuUQLfxM9c VZmsm3DRcyJOglGxOjXpfpZC5DUEBfHgYHObQLOA.hQOAJn6Kzd82ACn6F9BMHzWFTQL5v3C.LZJ b42ytx_y1CwmIdQ0Ge.xap9PZg7iQ5PPrG6tSplyMpuuggKswWkyROMRCX2.0c_t26M0UTGwvWZU iXcIxoJPv1c9M.a0Lba3TEgw1IGVWW1b9olRlZ2Li3EBQ66ws9SVbM9mwk8Dod1xkkoFw_NNmhja bnX5AL4Lq_EkBKvL4pmwO82ulScrHafaxz9xtDy_bDiU4AuhVmG0K2ben_49yb8XXpX6htibciaQ Ev3Q776yQVcydXAzJc2Zc8Go8HJ2Y_BbGp0b81y3BTAZtHvK9eKfPew0of2Xm2PJP4_WrVbQEIXt 6t1NG4Nsi7U8b2F8.3.gSeY.OIXsY9RRKHSsdw07eIwZOLkWXCdwEzSffW5zcM9q8EoJapkO5FQk UGiNt6RoFTq5_DcA5RwDEXmhdTOMK3Sxu0NSc1X8A_nVyF9TyvHy8f4c1AZG_PVX.0Tgknfq4Ie2 buBV1lMITd3uvR9cSoifvmM8dFH2fcvEOue0aasMv5UDJitruoTxdmIE3TgjYTRSkJah6.GH5fv3 uK4DZFk14xuuhQzCdEedr5.Eu2cWnD4M91hQh8P3_2To8h4APSGFBKp9sI51XKi1RC3E0Gt8eqJN f1qqnWe3jEMOApUEUEmc4jrdp6JltC9QecQylM4gNI2UtAJdX1e9pbjh5WMZdVuGgKuV0bBiGm83 Btro- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Oct 2022 13:53:34 +0000 Received: by hermes--production-sg3-cf9dc7f8d-qc2lq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 947e0292aa20223eb7e33a5d63692f4a; Wed, 05 Oct 2022 13:53:30 +0000 (UTC) From: Po Lu To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <87y1tuv851.fsf@yahoo.com> <87pmf6v7hy.fsf@yahoo.com> <835ygytmlp.fsf@gnu.org> Date: Wed, 05 Oct 2022 21:53:26 +0800 In-Reply-To: <835ygytmlp.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 05 Oct 2022 16:40:34 +0300") Message-ID: <87wn9etm09.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20702 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 150 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: gerd.moellmann@gmail.com, alan@idiocy.org, 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > Maybe those windows were deleted? No, it turns out to be a different problem, as Gerd found out down-thread. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 09:55:31 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 13:55:31 +0000 Received: from localhost ([127.0.0.1]:56962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4rz-0000xG-2b for submit@debbugs.gnu.org; Wed, 05 Oct 2022 09:55:31 -0400 Received: from sonic303-21.consmr.mail.ne1.yahoo.com ([66.163.188.147]:39913) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4rt-0000sM-KW for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 09:55:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664978119; bh=du+P7Zgd59LNQimZbTfncbBxsYw1Rv835qxP4FVOYkY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=ZtQ7BUv5ppkObf3uOHl3Nl9SOOg7thMMgQ8PnaGbWuhmMave5wGmjVPh9kzZmewOvOSUnrpriPZXYkzkdSdDqGJowEG8ndZZH61yTl6f0AQJE4F1W2iyrEYyOmBlw/N6znMhqkMo5PHT4fPtqNGje+WSnF0PioM7LmEAh4pqlj2rDGeM6LddZC8sMk1A3JSaU13w43wmI6o6Ek1vI2jjGWCUifYznYEJL91dHk7NOZkK4lPoZwCeJN0q3oKgw9MicSvRKxliWE4rdhh/uYPw1vyAAeMUZA3yFftSBv6Nr/ZT8Wh3DmVloAnhmQ103tyH0VC7DGha8XJYwcg9fSFvcQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664978119; bh=A/raBdRW5izmHrxURf2z+gVrCmTDuE9eljVNL/2IFUK=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=mn2LSces662erpaRBUe3pcnA2PyP70pw0DN/dZyvUH04yKNrnJKoL2Uv/N1RIsYxT0a5+yrTZqQK1v3SVMouUm2cuPsCpmZRpnLYQ9z0moggfRMkOZl+Jsvtsb2Wv8st8ko2eMOj60YM96OC8aRF21TpjoUnRL2+YA3kdG7NSk6W9dV/tsacnPg5zVgF3Gz7riD84hqxACK5hhyS3YoBXRkG4dSau4sRBBEDcCMwYtDzLQTLLrC9oZ+3d4FCj5SV2CSnWPlZjdPLZ+71H5ttyCwYWNz+CTW1/4N6sHdUf3IZihP3ZROfySrcKvLhhIXFGfy5/alZTHBbooMxwAOgaA== X-YMail-OSG: 8AZXMMAVM1mch43qDFhLSx4y5Em0QrafwRleUPT5kguFlkI2KRYHFh.Q2s1VMUs JkbBTv_jATkLliK_NgcLtCIEtqvKeiuZ3p69Arpclfo6ZKCy2bjW4v6rlBkQ_q5VdDZ2cg5RVRkT T9ACg1yIWRDvq8pDRrdygMKQheIIxLdIiFPKWCOBtm_Mgo7tRSIhneeLR8_O7xe3U6hFRBYsIMRh bEBFLxAZudEtAHc8huMgInLE3xa_ycXv4KplGq7tc.qNSirF9vYyFOCFTHZRi8AcMRJS3k7PYd20 VVKVAFyT.u7tuIhEWXU91yYG8JVnl9xtYm3JHQIvwVBHSyRhGRgeVLaA0.Cz5NVnajqVH5xZGib9 6zbIwJyhWo0chE4SkfyWR1CX4nsVZCAO34R1CWB6rh9tbFOTioa1mSfJ4TirtT8sUaHGIhtgKGQ2 yuqWBQDQd1qdRrkAxD9OaFAvnt0Nx8HWX.y_Z8i48rwu5gjqFKVZwZPJZdsWUrJ6SzqCJULXKbZc tH0Hq2a1T0zn6OX8HchNmB.C7wf3suurlqIcN5uK91GX8UKUhfOQpuNk2573pbgVfVbkDE.a2UGv b74uS4aPNaEfKq.Vzd57imE5J5W91YO1PMh6MuZxZz65s5Duaf.hPWGrs5VxhsAQptKc9LWWGTuX I2XyojpgMcfHDwxpiO0J.3jtcZPE00mMkXSAm8Qvn1UmPYwD1EYbKj5NB_LNXGCHXe.NUSRhzjYj PPmThXT6XOM.XxVCFet.dRXo8X6BArGGl7FiUzmN2UuBlKQblgRerHSTAQ.tnkwp_rf.GVMPzvWs zp7H7JyIZQ94kn8d1YU7c.6Vumme.oajoJ.gpnxvCFADxs7aQ9L7uhKvdFUyO7EauqOK_eDzRCU4 qMOuCNCcCsS0aWz0YeTV2apJKZp87ibEp_mGZCosMmMQRAdzkY5exXNFqhYNDHqRzKFYqlAoAQir Y6y7FV6ytFqtSHq_72chTJ3vJM.7BcTlgexAxfqV5X4lw0Fu8Tmw4IAZC6pAL9ffd1fnRlpordTZ ZVewJ86chqRNR5E0AwAcu14XSZ77QBmyxnbs4YANDiJfLgdc9SMNrtquc2ZjhI4EDFWirNOM83sm 6SRYl31UBhbAKNlNEUfTuM84PzAGE07avT30vd8N6iORijJ0_dCwWCrl_xVszpabeZhdyLDNPKGw wuBf81Z1k0lqmoh2v0pTgbkSkUZy09IKQxRYkXRwk4jzSjSFD2n2WILSoV_9BoNDpsnmQTITfzH8 XGNaJSIHohDmRoN.s7rzayRaRNMCbV4UPLYUI3GymA6E520NwfA5c1mtz1YcIqe8.Lp4bab8lDsf ItDbulzrS.m_uB2UQO8k.IQhu0p8rrgHS88HTu61QCShYeGALuuskVa7zMWnerCOByoTGXGHDqwR aVOOCoitfDx0dfG9CXX67kCjRnPyW1B.3Q.Ha0cccj4YP6lxWWp.Puo6sklpEL7QrFyyuEM5.Df6 B2jeHsMzm_rg5LnQhp.1XkbrY4d1I_o43awsS53Z0cT220jTklLYDGINk_BtrZWj2PD5F2NS2IlT 7m3.LvjuCXMfcZ0WS8TPfOwq8f5tljiAvoD1j8paXl5W6iSDJhL3ZnI9AiiGqi8Zv90QS3Wx2RuW d0u3lFIk0ChOKBuh9Zsgn0ECVKnIHvQD4VByoQu0l6WgVMMndVXTytK4u70M2M9CSI_uoBEmBG9h tDrGk4.BU80q0JctAohzsJFtpwhbXgGmPBZPKcdCZw2teRylekFpRhpXcRQLK0rjuvirqpM2_vQv t0v.hKGB40a8dcFR4MLnJUurxM84eXC8LQ67fSjTB3skgccWK0VhADTk.pTEH3ceB1i74JEjwd33 d5o1m2HgJ0h9gEXS4XTPsdgEPP__7moRoQtOu70OxmUIO53n6Ok83hOVdyfs.ahz_JnkDhCB2GzJ .wzHlJbOlyABGF7NNq99ogS1lanT9r8InbiyEvLMk3NTp00hgi6LrU8eFZiD6lvPd35AHdEWfxKZ o2vpmtf1gxHqIiBzGF8Y5CpccLPk0L8hxSoOz7COopJ9zOHuMhG86Temjf5ZBEpLNNHECAk9YnSt iojio078YZVJSUxl7pjbONngpFUCQ9QkqHbDThNTgAHJ3hZfrImdcP.Z_fh469TBg9l8i6D_Kgax E1oeX0wYBQsLxKRIGSIZm7vzuRGJOhEmzSTOTzo3IqrjU.e_IIXOdtyrHcZsLkAowC_SDpkQVwU9 S5dfMypUXvtNByEJXVPCUNmMLqowwCXrTG_1DhpTiZJKibbKxU2Xws0Naf8iqgq6y4GU7SisaN6N B4KU- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Oct 2022 13:55:19 +0000 Received: by hermes--production-sg3-cf9dc7f8d-4879b (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 28db9351f37c6d3dcf9b5cdd335a6566; Wed, 05 Oct 2022 13:55:14 +0000 (UTC) From: Po Lu To: Gerd =?utf-8?Q?M=C3=B6llmann?= Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <877d1ewnx0.fsf@yahoo.com> <83a66atn7k.fsf@gnu.org> <9e74f14e-cc2d-fa34-f9b3-5e0ebf500273@gmail.com> Date: Wed, 05 Oct 2022 21:55:09 +0800 In-Reply-To: <9e74f14e-cc2d-fa34-f9b3-5e0ebf500273@gmail.com> ("Gerd =?utf-8?Q?M=C3=B6llmann=22's?= message of "Wed, 5 Oct 2022 15:31:10 +0200") Message-ID: <87sfk2tlxe.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20702 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 343 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, alan@idiocy.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > I don't know. What Po Lu said sounded to me like it isn't specific to > macOS (safe_call in event handlers, IIRC). Yes, and there are also finalizer functions called by automatic GC. So unless read_socket_hook does not cons at all there is no way to stop it from running random Lisp. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 10:09:20 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 14:09:20 +0000 Received: from localhost ([127.0.0.1]:57755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og55M-0001Tm-HB for submit@debbugs.gnu.org; Wed, 05 Oct 2022 10:09:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40502) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og55J-0001TX-Gk for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 10:09:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54092) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og55D-0005r3-94; Wed, 05 Oct 2022 10:09:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=izD8b2C+DfalzQupXHYLEdqRDYEVK8qBsqiKSlUTUMY=; b=bW+SQXI5tRfO inZZ8Zs2kZtxP2msvdBZ1RT7DEC0Tkhb3/R2uD6brd2vQVaS1PUNks2zoNlxYiAMJasIlyYTlhEQk DecfdTYFZnybKXklm6TC4avIRkwZ9yJIcwjNNjxoAe3fYgEHUAsaa2ABCUL4rgzwg3TBzcO2vjjTC lEAI85L0n2TG2zWsUAAT+JckD/1Ls/5ZuRDMZJv6Obyi9jNxPZ84Vn6+HZvM77N/TNxv6VUcl4ZZf uHjCbclsn7Llev3CoYQ3V8SRw8/+dUsHomeoBJBqJ3j/0GlM6GruLFgak7ow+EHSnX5BCwKH8Dejl xwZd2+sqk3cm/UoDerKT1g==; Received: from [87.69.77.57] (port=1625 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og55C-0007rp-JM; Wed, 05 Oct 2022 10:09:10 -0400 Date: Wed, 05 Oct 2022 17:09:09 +0300 Message-Id: <83zgeas6pm.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <871qrmv0ln.fsf@yahoo.com> (message from Po Lu on Wed, 05 Oct 2022 21:52:52 +0800) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <877d1ewnx0.fsf@yahoo.com> <87tu4iv7w5.fsf@yahoo.com> <838rlutmqo.fsf@gnu.org> <871qrmv0ln.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: gerd.moellmann@gmail.com, alan@idiocy.org, 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: gerd.moellmann@gmail.com, 58042@debbugs.gnu.org, alan@idiocy.org > Date: Wed, 05 Oct 2022 21:52:52 +0800 > > Eli Zaretskii writes: > > > We call maybe_quit in many places, basically anywhere where we have > > potentially long loops. It isn't just Fmemq. So if we want to > > prevent maybe_quit from indirectly calling arbitrary Lisp, we'd need > > to block_input inside probably_quit. Which means > > process_pending_signals will not call the read-socket hook and will > > not gobble input. That's bad, I think. > > > > And note that this is only problematic on macOS (AFAIU), because there > > the read-socket hook can trigger redisplay. > > There are many different ways to trigger redisplay from the read-socket > hook in the Haiku port as well, and I haven't seen any problems there. > > Besides, any call to automatic GC today can run arbitrary Lisp through > finalizer functions, and that includes redisplay. So unless the > read_socket_hook does not cons at all, there is no way to prevent > probably_quit from running Lisp code. That we have other loopholes doesn't mean we shouldn't be concerned with this one. IMO, we should plug all those loopholes one by one. Finalizers are very rarely used (not at all in core, I believe), so it's a small wonder we didn't see bug reports. As for Haiku, how man y active users of it exist, and how "crazy" are the hooks they define for redisplay to call? If those hooks remain nil, nothing bad will ever happen. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 10:10:43 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 14:10:43 +0000 Received: from localhost ([127.0.0.1]:57760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og56h-0001WO-0a for submit@debbugs.gnu.org; Wed, 05 Oct 2022 10:10:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og56f-0001W9-K8 for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 10:10:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47076) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og56Z-0006DI-NE; Wed, 05 Oct 2022 10:10:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=k0sZeijDSMOg8AaBAqtsAXM37+lSOZX9teVznbnr29A=; b=eEVbzemGq7rq wVo/BD/YDga59nL9uOP7Ai1VlV6b9IFFzZKrrKgk4CY40E4GHkF3KGDvEHcJ+A6A7kqCEnT0PKhNj 9kHJVX/imXKK8ubd9Ktb1lpbq1cY7wohDQ5gRsgabtd/t8pAXJqHkXXKgDhUa9YkE8k48fOHn9Rzn 1o0bxZhXf50IrYKGXCOVNjH8tzfF6WYd6MIdXVg3nnvXhv0ij9VMXkij6K0/XVHsQPgphTD+tG69w rAz7xmS+IAi51pSpk+fEhVq1dhpBmcHGv4Bw4vOmApFYkBuPNT7Qcu2gfbLlUonDp0PozhBCYAnRw 7rWsIkj9eUAuwciKDul2nA==; Received: from [87.69.77.57] (port=1712 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og56Z-00082y-1Y; Wed, 05 Oct 2022 10:10:35 -0400 Date: Wed, 05 Oct 2022 17:10:34 +0300 Message-Id: <83y1tus6n9.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <87wn9etm09.fsf@yahoo.com> (message from Po Lu on Wed, 05 Oct 2022 21:53:26 +0800) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <87y1tuv851.fsf@yahoo.com> <87pmf6v7hy.fsf@yahoo.com> <835ygytmlp.fsf@gnu.org> <87wn9etm09.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: gerd.moellmann@gmail.com, alan@idiocy.org, 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: gerd.moellmann@gmail.com, alan@idiocy.org, 58042@debbugs.gnu.org > Date: Wed, 05 Oct 2022 21:53:26 +0800 > > Eli Zaretskii writes: > > > Maybe those windows were deleted? > > No, it turns out to be a different problem, as Gerd found out > down-thread. Are you sure? GC can only remove dead windows, no? From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 10:24:52 2022 Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 14:24:52 +0000 Received: from localhost ([127.0.0.1]:57770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og5KN-0001sP-OH for submit@debbugs.gnu.org; Wed, 05 Oct 2022 10:24:51 -0400 Received: from sonic316-20.consmr.mail.ne1.yahoo.com ([66.163.187.146]:44835) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og5KL-0001sB-Pa for 58042@debbugs.gnu.org; Wed, 05 Oct 2022 10:24:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664979883; bh=a/t6u9cRXaj+ltHf+u7TkS8X+6EhgTcVt2sSZ3fzKsk=; h=Date:From:To:CC:Subject:In-Reply-To:References:From:Subject:Reply-To; b=I0yxUqQJueLzWpO53BsDE9IQsFyP+tVv9ZckSauKI5SXXjfKF76aumVAfI0sXAIcLNavJkd3Csc8pXE0cyGMZZh1CG6/aP0cADvAbpn3UEzAdkENLEzFHOsxe1N4do3UeOmjiOV76ObMSvdoMDrd3onEYVbr+lcRScGB/Tc8FKgprNkqQN4Y2fhv5wNjqjBiU1PEqk8VedEnNwHMVJ4wSFjE6UD3BqNI1ekcE4HUTk2thqZn1ionhC2n0jPHWZNJqL+P1/pOQlLDjpSGM1UVUeYChwyoibTU49Q/LxKfXij6pUWB0Kxr+rPu8ClRAPAtadiWgVFnaN65cYISnWkTTA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664979883; bh=FxHH1xgxtxXazvngSTzEWrEE8EDZomqLLGOISFJaUY+=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=cwePss5aLvB+7sDcgQVnHjwg7H4UsJ/cYvKQWlQDNQT1glzb8yXgpJSIgXd7NA9euz7XQfl12sIXzZHQh2y9zxps8i2E0I2X1DoT8sPlKBk8V8YhHeOh5f11/l6piJN+6+n6U0yxTTaJg7CQVbL3J80PC8NLkQMQabgQs2wjHxmx1egeHOE1U7vCRqWuEetssz/mUJk6NR4KEvF+shDzOsSf2dEOI4iG4cVenG+e2t7co2PzRqV+EtxCx9OBqEQ920ONGuMqNtEZHJ8wbWz/TJNRMAO/Jbh2h92HuhyAKnLbVNInCtk4OyVBOvGzJz69sfolhs/4XpjWyZxnbCpB6w== X-YMail-OSG: gFrMuEwVM1nFJnzXm419rx2ScnBANIrFkwMNTf58AwnganCQ8gwmSVo9.vjh9P5 BVnGU.eZXQQ2ECeDAqKDfL1Efx9GZ21O1iKjkxUCyLW2_A6jG3.Eq78AjOgMlbVv78VtENOqw4oc 6jiFBRBzSdTp5VIDdS9G9Q8zWJrFEG_70RRrcnfbXtbPqA0rn7u6mpHCoZ.AeQ5x8cIGW8rIfQNB WFWF3TVPGy4SIhaQNctwUKLBxcMkR5VkeOz8kQgAK0RfmLtynYuVlG9N7c4cLzQ8za_c7m9VoQDt 3ewpQxPEaZp_Vkl_C662ccBjhlO9XZlLcDncBlY.q5KkX2Xe6xrVW5cEyNsqYHJxiCojNaUxrlYc iACjY0W3Ns3SWUor9SlYkyyzVP.yIcG0fBYNbNSbQA6annV.MEEAGPWHDS3uao2lPv7xSbRPkWm9 4GsXAIIOU9z_HetUhbsgmfSYMWES0y6.FJUxlawC3HkgqW6VjZZIhiiz45HsbjvyHinyNCwFa45e v9dZw7i84gwB3egvEgygcslSX78NhKj6veAPwtIlKr3NjPWRtBsVXBQLeGI0DIbTI7KWZP_urruK 9jC98VvDMV96qcezkPKTMNwqFQo7kJYOwocJEDZ0AC0eKm7LZo7DFJCWVB_psN0YCoqXZyzbvzjp n7CggpxMMhtezGZOSHrhVFU9.0yvUGnhiTw770DjyuTlTaHUE0XW96dKOPAgwa2HKUwoL4vob7js OXR6sDMYsCZpdN6vXwqZk1YBk89Ok85kiH.JaBC5W1ybd.Ebv.gSPv3le0gTzgpIHB2wlzygvk9B wc9YlVq9ot51RdxEOOzc2LEsCE4AzvSGT2g2K96NdwxKeMG7EfAOJWac5N8kUQy4KVTWTlZs0XZJ cJSgb270kQ38La496bksTQva4M653Qvq7JtyBCNfALB3inAoh_3IIuVpr0mpAWtwUdCSvdTHyQoj zh5HUct9aQXg7L6OMoYOx.Ltz3.NOhc3rfRkth5pmOeSVdu4IM8nb1yPAMJ.sRaL5CMkJATNFx2K 2Rj9vfpAXXhqvyL6T2O4U0IeJnoeG_qmHb80NIgtlbNirZnsXP38GS4nOX8mIF4ZHMVGR9WsdV1Z ZqCZmdFGASLT2e_4lOEvi1Y2V9q45aKrQDFU4nEzu0VSAr_Ish_d8Uwg8sYZgelIE3oMWExeo1Fn Y.npffREdgi.nWCwqVLMx3RZCNgjJx_x2W5XWBj5r7gMUoMb.Z9RuZexJExB8YnN0uMRxT3y1kPo Fu8z8VTt60qquILwpiDOvmAkwRuGN0FJZW587N0jbykdL9n2jCL782wuOvSK3wFjdm1kx_q8b2yG VSxVY.A9hTPXPWUQJ500bsP8VA.4otgoBiuP1AOI5RvNcK9jeo0Pk9lmpqnrq9DyFBBRA3sbYqtF 5n6A67RmDhlJA6_tQ5VVzHvDj4Ie8xRn2.nLIO4BLpPWvnVZN79lbDiPrCmiJHBEhS.juI7bJMP2 n81UuF7DUFDIr2FUQ3TczFaqcewCzRV6Oa3i14o2wTgFLEnM7RhM3qmRA8HyqFZTFABTvxq5DqSV mer.2vj4hyXz9EZMgWmhms4pz2CDV2rfEAW4HTcLRkS1.QVYjbfA52cSSJ2jCktEx9r7oY0YITBJ e.jyMgkpS5gYsFPDF3x.DJFhMONpSJDq.IomHUE4YphaQLDh2IjQdMBTIfAGxV_vJkrZ7w0e3_Hx vKiN7EYSahyKm0jUXZ5C_SePNUNLD3eCwEnlt4nWDgjvXGyESEMu8HRkjVCfl2o5yrEFJ6VIn9pB __lwkylZ1asW1fY_rIq7iPG6P0.2P5du7M..IzWudNuR7ulvdRP81bp6RjE_PhtLnbG6_8c_aHhI gVoCs.IrNQtL4nAJei4jEiTXJhiriQkaIgl3axdnlidHPrVcHP9lShCWgVf0jOG7ufT.Dr8rZQJ6 KCPzviVAWVjkCbrOtxWvF9l_pFRWBkKFa8yS_7GBZ8fugkC140LOiutd.z.X2sCpHw87.zxR5iaL uagd7fOCrR6ZL3hd6eVKCXYX7uLPAGYsX82HhMsw_Fk17VLAjMeGexMYcnc5OFIYaxlv5mb_fe9G HK_SJDPIp.B2uiKdq0p4IBZS49oMMKGU71K_IRM1LbibB4pS.J.OFpjCIsXs2jBrd5D0n9evkbOt gZNWUQyczhluuZoAMlozlAtUlpXNTYxGvzVuIrQl.TuXBmul7RY1..telJlR_6xOXNGew9uC3cr4 gLJUzPSKzP7PFsiKkogKultE_HplMEZymN1Skl7ztm6xFW7c- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Oct 2022 14:24:43 +0000 Received: by hermes--production-sg3-cf9dc7f8d-tskmz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 90ea3f0687ae3a276523520b9edd2ab0; Wed, 05 Oct 2022 14:24:36 +0000 (UTC) Date: Wed, 05 Oct 2022 22:24:31 +0800 From: Po Lu To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <83zgeas6pm.fsf@gnu.org> References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <877d1ewnx0.fsf@yahoo.com> <87tu4iv7w5.fsf@yahoo.com> <838rlutmqo.fsf@gnu.org> <871qrmv0ln.fsf@yahoo.com> <83zgeas6pm.fsf@gnu.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20702 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 717 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: gerd.moellmann@gmail.com, alan@idiocy.org, 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On October 5, 2022 10:09:09 PM GMT+08:00, Eli Zaretskii w= rote: >That we have other loopholes doesn't mean we shouldn't be concerned >with this one=2E IMO, we should plug all those loopholes one by one=2E Judging by how long the NS relayout code has been installed for, and how i= t has not actually caused problems in Fmemq, I'm inclined to wait for someo= ne to complain about memq not working before we remove it=2E I tried sever= al months ago, and removing that call to redisplay resulted in the system r= efusing to resize the NS window=2E The call to redisplay in the drag and drop code should not cause any probl= ems, as that hook cannot be called from ns_read_socket=2E Thanks=2E From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 06 01:20:13 2022 Received: (at 58042) by debbugs.gnu.org; 6 Oct 2022 05:20:13 +0000 Received: from localhost ([127.0.0.1]:58541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogJIr-0001Wo-0E for submit@debbugs.gnu.org; Thu, 06 Oct 2022 01:20:13 -0400 Received: from mail-ej1-f46.google.com ([209.85.218.46]:36859) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogJIn-0001WY-Vt for 58042@debbugs.gnu.org; Thu, 06 Oct 2022 01:20:11 -0400 Received: by mail-ej1-f46.google.com with SMTP id 13so2095532ejn.3 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 22:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=c2OOALpOZ7yvtfJb/QbiDW7LcAbHMmNg5GVuGe40ocY=; b=DptBXF3bpU6txY723OF9MFra2uYTwj7tWH5qZY8myfs0SfYmCfZVhTz5o48q80JOMf ztuNdq8/F+2lEum98Ysm31HtdmActzL5giFVLchIOEU1bPXX2n1jHbVoUbxBHyGf+QIz fW6g08N4J8o07rdZ0K4+LH6UnTv/NS1auzlG3JnWlmjxTYUJ5jcFYvfRJg6xVsiA6sOC 4hFqK9Pv6tET6wpi3itCzht+VFf+w7UEfarUpuD8kPHusBP9NLH8pQ1E39hTbCkz4atX pGgEvQqzVZ0mgQbn4iYWSy8tFywm+Y89GwnMWuObd60jN0/iebd3d5Z73PvNV1QyaOCt IWRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=c2OOALpOZ7yvtfJb/QbiDW7LcAbHMmNg5GVuGe40ocY=; b=L/H4o/l3mqM0fedA3FoAL5ktw40ygINCpfsy/DpwpGGXZDhykIgNwQjVx9eL2+EMZu i+HImu5xoz68nxiX9nizcjawYIp/uynTcRj1GWm+r5BeMzbiZ2Bk0XxakA/OzeqfVj0C 1tdJkGLz81O28G74vNkyyk3xbKB5lBwPsXWpNDy3szDSidvMas8uaORNZ2Gs9Byz/C2N 917cWHGsNbFRkFL84Z6cZdQ9KWre+bQKtrxzBiMxXh8scbTADW5c+Hjgnao6TiZNzBkR gvQBLNw1e2OtivJ+/xKZXJNIfzIPoTzqwYl2eqYODgxJInE9ptRgKF0tZRl375i4EQtN sRPA== X-Gm-Message-State: ACrzQf3VTGUMWZgLPFLhBj2M8GjExRy60huirBa4E/MKIBovIHo/Uwbi lrtQutUCO5BI3JODcTq2uIY= X-Google-Smtp-Source: AMsMyM6K+jXKTgAo4umsMbKLM3BAxSErqRCRCZ9NKbgpXPybM4lQblaZTBkB4f3q1Tt9ilhhkK7Pog== X-Received: by 2002:a17:907:168f:b0:788:c642:1624 with SMTP id hc15-20020a170907168f00b00788c6421624mr2553156ejc.79.1665033604069; Wed, 05 Oct 2022 22:20:04 -0700 (PDT) Received: from Mini.fritz.box (pd9e36a85.dip0.t-ipconnect.de. [217.227.106.133]) by smtp.gmail.com with ESMTPSA id g2-20020a17090604c200b0073d7bef38e3sm9596702eja.45.2022.10.05.22.20.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 22:20:03 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Po Lu Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <87czb6v3l2.fsf@yahoo.com> (Po Lu's message of "Wed, 05 Oct 2022 20:48:25 +0800") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <87y1tuv851.fsf@yahoo.com> <87lepuv5l8.fsf@yahoo.com> <87czb6v3l2.fsf@yahoo.com> Date: Thu, 06 Oct 2022 07:20:02 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: > Gerd M=C3=B6llmann writes: > >> I don't get an abort, but the ASAN error again > > Interesting. > >> =3D=3D67682=3D=3DERROR: AddressSanitizer: heap-use-after-free on address= 0x000107130d00 at pc 0x0001002a481c bp 0x00016fdcc3c0 sp 0x00016fdcc3b8 >> READ of size 8 at 0x000107130d00 thread T0 >> #0 0x1002a4818 in PSEUDOVECTORP lisp.h:1110 >> #1 0x1002a4888 in SYMBOL_WITH_POS_P lisp.h:1122 >> #2 0x10025a338 in EQ lisp.h:1342 >> #3 0x100280eb0 in run_window_change_functions window.c:3964 >> #4 0x1000f18c4 in redisplay_internal xdisp.c:16600 >> #5 0x100107bf8 in redisplay xdisp.c:16111 >> #6 0x10089364c in -[EmacsView layoutSublayersOfLayer:] nsterm.m:8661 >> #7 0x1900a9624 in CA::Layer::layout_if_needed(CA::Transaction*)+0x22= 4 (QuartzCore:arm64e+0x20624) >> #8 0x1901f661c in CA::Context::commit_transaction(CA::Transaction*, >> double, double*)+0x1c0 (QuartzCore:arm6 >> >> frame #8: 0x0000000100280eb4 emacs`run_window_change_functions at window= .c:3964:7 >> 3961 (de-)selected as its frame's or the globally selected >> 3962 window. */ >> 3963 if (((frame_selected_change >> -> 3964 && (EQ (window, old_selected_window) >> 3965 || EQ (window, selected_window))) >> 3966 || (frame_selected_window_change >> 3967 && (EQ (window, FRAME_OLD_SELECTED_WINDOW (f)) >> >> (lldb) p window >> (Lisp_Object) $18 =3D 0x00000001071c2935 (struct window *) $23 =3D 0x000= 00001071c2930 >> (lldb) p old_selected_window >> (Lisp_Object) $24 =3D 0x0000000107130d05 (struct Lisp_Vector *) $28 =3D = 0x0000000107130d00 >> >> old_selected_window looks strange. It's a global that is not >> staticpro'd > > Isn't old_selected_window supposed to be kept in sync with > FRAME_OLD_SELECTED_WINDOW in old_selected_frame, with the latter being > removed once it is deleted? > > Would someone who knows the window code well please take a look at this? I've submitted bug#58327 for this problem, so that it won't be forgotten. (I'm sure I will forget it at some point, because I have added the staticpro in my local branch.) From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 06 01:35:38 2022 Received: (at 58042) by debbugs.gnu.org; 6 Oct 2022 05:35:38 +0000 Received: from localhost ([127.0.0.1]:58563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogJXm-00022A-75 for submit@debbugs.gnu.org; Thu, 06 Oct 2022 01:35:38 -0400 Received: from mail-ed1-f52.google.com ([209.85.208.52]:38603) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogJXj-00021u-77 for 58042@debbugs.gnu.org; Thu, 06 Oct 2022 01:35:37 -0400 Received: by mail-ed1-f52.google.com with SMTP id l22so1262072edj.5 for <58042@debbugs.gnu.org>; Wed, 05 Oct 2022 22:35:35 -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:to:from:from:to:cc:subject:date; bh=5xri2+ORbSr7WQwkSDylKiz+vaRWLyEtpGCwu/wjP5M=; b=EJGa3ygAETigAhWLEu4C9rwVLpfaNEWkuy9Gikya81Wo382cI6QOR7gfgWUnm6H6+E Mk9DLeJ8e/9uswFkYT+Xv/WNbJxC+LXH9YjUcr78FxuhrH4chsSA9KnFIEQO0ETQihmg 9mZq2pu7ecJwZmmsIp/PfVwAKLxtjle6eqLydwGYnZwvNJvdJCxaDwP5eSRpl+R9YvlJ doGdII2j7UsH+VPqK89H/UVLtw0ReqsM5JWOV9Y9+ZPm64ErvwFFj0zukgTjyBw/zaf1 iI1LFPRsGWY5XTNLZXLEXA4klJRs/z7htOlYKbKrztMLLHHs5h4O7Uw17gWEL4iWH/WA r+uQ== 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:to:from:x-gm-message-state:from:to:cc:subject:date; bh=5xri2+ORbSr7WQwkSDylKiz+vaRWLyEtpGCwu/wjP5M=; b=nUn6pG2QF4O19FR7A0nBe0mFF0/eeWtA/IalOXFU7xCiuJrbv7jOXByKTkiJroZ16g brLP63bO14wFrNlU0MR78p7FBnsQuwEcfJCpcCIg5Aa4HjfvGwcRal24Ef29sHbTRjP7 B1UWY7Ry3oAARQ1Dj1tTkLfQImakyyNL3bk8HABtpYNF9hbYb7shU7TteEjFElpsud3g lmApHyAoco2OHXRwxlmO/Skj04r0gBpE3WXaGjTjFCDa6o/3YmgFDDBA3xToyktqMymy RwEVoF239h8x33FPBrbNz8XQWs/dvIP7Fkm71NGi3Winhn3UZ7+dtEfG+uokH4RdVG2o zerA== X-Gm-Message-State: ACrzQf0agQ4uYGQG4d4moyWelhWk2WDIjqHiIbk+mO7nbr0OFN5otHRn S8izV+mEJwMj+1koU/Dd+s12jkF4ScMWNQ== X-Google-Smtp-Source: AMsMyM7E29asy7OpYWEY8AvWMzCd0HGXtxJfMIxVXiYA99k+NCpg2Uxg9GWrBczvJNqhhvAMR5ALzw== X-Received: by 2002:aa7:c607:0:b0:458:fe72:4756 with SMTP id h7-20020aa7c607000000b00458fe724756mr2950874edq.423.1665034527812; Wed, 05 Oct 2022 22:35:27 -0700 (PDT) Received: from Mini.fritz.box (pd9e36a85.dip0.t-ipconnect.de. [217.227.106.133]) by smtp.gmail.com with ESMTPSA id 21-20020a170906301500b00738467f743dsm9695091ejz.5.2022.10.05.22.35.26 for <58042@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 22:35:27 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: 58042@debbugs.gnu.org Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Sat, 24 Sep 2022 15:45:39 +0200") References: Date: Thu, 06 Oct 2022 07:35:26 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Can we come to a decision about what to do with probably_quit, based what we know now? The threads under this bug are a bit deep and complicated, so I'd like to make this a bit more visible. I think the problem has been analyized to be: 1. The re_matcher uses char* pointer P into data of string S. 2. The re_matcher uses maybe_quit 3. maybe_quit can call garbage_collect 4. garbage_collect can call Lisp (finalizers, redisplay) (4a. That Lisp can again garbage_collect) 5. One of the GCs can relocate the string data of S in step 1. 6. P is then invalid. Possible solution: Inhibit GC in probably_quit, so that P remains valid. Q: Should we do that? And if so, when? From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 06 02:59:30 2022 Received: (at 58042) by debbugs.gnu.org; 6 Oct 2022 06:59:30 +0000 Received: from localhost ([127.0.0.1]:58676 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogKqv-0004Ft-RO for submit@debbugs.gnu.org; Thu, 06 Oct 2022 02:59:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogKqu-0004Ff-4U for 58042@debbugs.gnu.org; Thu, 06 Oct 2022 02:59:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42582) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogKqo-0000Wt-Te; Thu, 06 Oct 2022 02:59:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=IMWPnme+e5Yw+47KmIBaTqV7TDvugykmDG6Mw0rXUfo=; b=O4JHnPvERDnsnm/r44T3 Bokubgwv+B2i+ceGaUjFSKG5MNvpQsZtpWtGDT5y+aegTmIjB+qeAt4er/x4gVgu91IBfYWibDvtA stNuMzhZzub4vZkknhEhYKTHtCJxVzq1hmiFTzQkJ3Kbri69lvD0XE5ma78gvgMS8bee8tWh+d58U +p9eoltXar3jsqJTsmQConkM9XUzROY5C5tBYUg0O1CAaGtOdXyPnBeenBk6Y7psa8mjapPmra73M 2WPkJx1tUINz+laTeoCEeKyy6GijIIFzSEDC2K6ss1oQ9hMgugUMzTQYKr2p7j30BAAlrzJygjAOW pfNoLcNcgiOJ2A==; Received: from [87.69.77.57] (port=4106 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogKqm-00067y-GB; Thu, 06 Oct 2022 02:59:21 -0400 Date: Thu, 06 Oct 2022 09:59:21 +0300 Message-Id: <83edvlqvxy.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?iso-8859-1?Q?M=F6llmann?= In-Reply-To: (message from Gerd =?iso-8859-1?Q?M=F6llmann?= on Thu, 06 Oct 2022 07:35:26 +0200) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Date: Thu, 06 Oct 2022 07:35:26 +0200 > > Can we come to a decision about what to do with probably_quit, based > what we know now? The threads under this bug are a bit deep and > complicated, so I'd like to make this a bit more visible. > > I think the problem has been analyized to be: > > 1. The re_matcher uses char* pointer P into data of string S. > 2. The re_matcher uses maybe_quit > 3. maybe_quit can call garbage_collect > 4. garbage_collect can call Lisp (finalizers, redisplay) > (4a. That Lisp can again garbage_collect) > 5. One of the GCs can relocate the string data of S in step 1. > 6. P is then invalid. > > Possible solution: > > Inhibit GC in probably_quit, so that P remains valid. > > Q: Should we do that? IMO, yes. > And if so, when? "Now"? From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 06 03:21:58 2022 Received: (at 58042) by debbugs.gnu.org; 6 Oct 2022 07:21:59 +0000 Received: from localhost ([127.0.0.1]:58731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogLCg-00072q-KN for submit@debbugs.gnu.org; Thu, 06 Oct 2022 03:21:58 -0400 Received: from mail-ej1-f53.google.com ([209.85.218.53]:43751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogLCf-00072d-8d for 58042@debbugs.gnu.org; Thu, 06 Oct 2022 03:21:57 -0400 Received: by mail-ej1-f53.google.com with SMTP id a2so2507239ejx.10 for <58042@debbugs.gnu.org>; Thu, 06 Oct 2022 00:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:references:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date; bh=TCSp+GJzqh7i7TxEtmVzYyuFERiUUfz+/c7Ddg/Zs8E=; b=kYZNtO5Lv8v62OAmnWIQ+H08Hdjl02qJIdld5tOAEity44fMjH5rwP+ro1YCWPRRlR VQtlQdxgMtUhORnxxQZa8U+MwugI5vlNDiD4ukb1nDGmHbzgIm3FUbvnzQJD0ET+3duF 4SwU8eChRCOjNh/YgNm7lccYp84ZWp1quk471k3QJEvuIxum2Nlc4OocZc8bFF4EB6v/ ObyT+OhaehQZfc/bFnjOHPx5sl5Dx+OAWJ4H7BCkRVKm3KEb+HgCyO1fD4CB/oiBExJB WqYcflesg4O3TqNJe6YWJoERZbcF1lMY3EiXy5jORtIhZQThoHY3GgXm+6+9qNj493gz 4A/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:references:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=TCSp+GJzqh7i7TxEtmVzYyuFERiUUfz+/c7Ddg/Zs8E=; b=ea8G1UeolAgfsk48K3gOW4PmlYqtjYPaBdKJ41e8hq12bUDp+bJi6o7bahJmuVjqMo pLT+fCm6n5PT53ZTp+b/h8ko+x69/cA5+++reBEbd1ZHbkfdwTCJyK8VTg5VhFjhgoXU VSK/qVbRiCM4qKILqswMgwlw9+8Ek5ciNMmtNHUHziCN3jVfKWL71wwBJYzLVGBjMEwz PFl6flQmySBYi8DnIDzpdtyjjBHq3rIysMCgPG9uxtkhG1wlownqjvIH2FJ9tIgWotIo ckwx4s8wwa0UDKrEGal9xWItYsFx5WkhQKQj0f59IZMMOehaUxe13eyo1iCaQAxUrWJE bZwQ== X-Gm-Message-State: ACrzQf1FNj/+0Zt/yWyUD1DWRxpdbynG7ByURfT0AGEigrMDFfrTXWNr Q87zG+KsveRty/lwTASlHBIJby3xur/lQw== X-Google-Smtp-Source: AMsMyM5UqFmwTB3pBjDqp0T7rx58lBGqHKaIbrVSatQWA1YOy5RxULW6zPcR5aDtjVxl7F9rm5Jv2A== X-Received: by 2002:a17:907:2d88:b0:78c:f800:7252 with SMTP id gt8-20020a1709072d8800b0078cf8007252mr2898675ejc.441.1665040911244; Thu, 06 Oct 2022 00:21:51 -0700 (PDT) Received: from [192.168.178.21] (pd9e36a85.dip0.t-ipconnect.de. [217.227.106.133]) by smtp.gmail.com with ESMTPSA id f13-20020a17090660cd00b0077a7c01f263sm9790360ejk.88.2022.10.06.00.21.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Oct 2022 00:21:50 -0700 (PDT) Message-ID: <925e9a8a-3271-615d-0e7e-0710dc871ad1@gmail.com> Date: Thu, 6 Oct 2022 09:21:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Content-Language: en-US To: Eli Zaretskii References: <83edvlqvxy.fsf@gnu.org> From: =?UTF-8?Q?Gerd_M=c3=b6llmann?= Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <83edvlqvxy.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) On 22-10-06 8:59 , Eli Zaretskii wrote: >>>> Q: Should we do that? > > IMO, yes. > >> And if so, when? > > "Now"? Done in master. Thanks. Not sure what to do with redisplay, or Lisp in general being called from event handlers. I tend to close this bug, and submit a new one, ATM. Maybe we should at least think a bit more about what the consequences of that are. Or maybe not, because it seems to "work well enough", and I wouldn't know what to do about this anyway. Any preferences? From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 06 04:08:20 2022 Received: (at 58042) by debbugs.gnu.org; 6 Oct 2022 08:08:20 +0000 Received: from localhost ([127.0.0.1]:58819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogLvY-0008Hv-FD for submit@debbugs.gnu.org; Thu, 06 Oct 2022 04:08:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56112) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogLvV-0008Hc-HT for 58042@debbugs.gnu.org; Thu, 06 Oct 2022 04:08:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:32942) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogLvO-0002F2-TQ; Thu, 06 Oct 2022 04:08:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Gpl3UKwAF8v7j1Z+yS9TdhGqELWHDF3B9NxrPeu/chc=; b=kok7H+ZHp5Qaz8knfYKN mdTVyWTGgQTM5Uj9p02JjiVHSZFwS9UAP+1ieyzO+3l81wu95F3DbFw4bDLdpITo/pOEB3CAl69RM 9cPXN3VsbZ9Cr3fRIesXmvcnwb9mvBR8mTZYaamTYvmJ7YfG0EZIiL0tyuH2LTh1xxnlHhUC9hfR8 Gi9BLr5G8pM6wBPyReMXGscU/zUCzLKDGTBxal1FMWGvSIp55bAAKQOdz8GmhChtYg3RUsfSNdQCr ZCVLYcC9NvK8Vs1+8+DMF9BzD9z/BEdNB59NvwM3JLyFrXP+rZ29pESHmdBKzoZRSHP/OUVC4z4YH NGiLruUl6nXlOA==; Received: from [87.69.77.57] (port=4348 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogLvO-0000gF-2i; Thu, 06 Oct 2022 04:08:10 -0400 Date: Thu, 06 Oct 2022 11:08:10 +0300 Message-Id: <83bkqpqsr9.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: <925e9a8a-3271-615d-0e7e-0710dc871ad1@gmail.com> (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Thu, 6 Oct 2022 09:21:49 +0200) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvlqvxy.fsf@gnu.org> <925e9a8a-3271-615d-0e7e-0710dc871ad1@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 6 Oct 2022 09:21:49 +0200 > Cc: 58042@debbugs.gnu.org > From: Gerd Möllmann > > Not sure what to do with redisplay, or Lisp in general being called from > event handlers. I think the conclusion was that block_input is the solution, and should be used where necessary. > I tend to close this bug, and submit a new one, ATM. Maybe we should at > least think a bit more about what the consequences of that are. Or > maybe not, because it seems to "work well enough", and I wouldn't know > what to do about this anyway. > > Any preferences? A new bug or maybe even nothing. Because we don't have any ideas for how to solve such a bug in general. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 06 04:23:49 2022 Received: (at 58042) by debbugs.gnu.org; 6 Oct 2022 08:23:49 +0000 Received: from localhost ([127.0.0.1]:58869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogMAX-0000Go-7c for submit@debbugs.gnu.org; Thu, 06 Oct 2022 04:23:49 -0400 Received: from mail-ed1-f41.google.com ([209.85.208.41]:38773) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogMAT-0000GW-RR for 58042@debbugs.gnu.org; Thu, 06 Oct 2022 04:23:47 -0400 Received: by mail-ed1-f41.google.com with SMTP id l22so1733464edj.5 for <58042@debbugs.gnu.org>; Thu, 06 Oct 2022 01:23:45 -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=UGxnUZ2IN4oegKzK2vMS2oPfdvwsZqK5pGNNUbEp/QU=; b=hah6NB2mNaMf+W5EtY7iX3xFJ/dBiMXTPaICB7UW+zz36YWoNCr44/Wn/3m5YOhzmx JZ9hSesE169s+kvzUSLOI9y8XRixdzVNzmxLwhjwjPb0QhTB39k7v7+Iw46CeZNsMTeS IgUDHjzsplYOUUqHeizT+JFcFonkGKm2VHeitMu2kFZ29T9Ay4BAm9NG9u9nFxzLnafy XeEFv1CKaW1x49O70euwmOOQ4OuywTk1L5WYs9zXBF7hK9T0bRCty4Qa6maZDihv1RsN XgrXodz6OmY4iL/FkZWPTJkzMO+qRojJyRijMRzKCkTQ/yXINALyZqz8522EBlMu5Aju iZRg== 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=UGxnUZ2IN4oegKzK2vMS2oPfdvwsZqK5pGNNUbEp/QU=; b=U2WNUhVJg3jVU0HqXoht1EGdCShr9otYz5ZbyzGzgmulSbXRnE0vxsNLGDQjEq44DB 7tqNqRhW6ChyEm+gXVnu+rv4Udg9lq/u9zes/6DTU6qb+EVcBuRlKYtySmmXgCuablOi eLmNOSI8BbGD+R/C2Pp9YClQfZGT1xDyhEKeACNvAt9K6rJ2YQ+kCOE+jMiyzp+i50td tAb7m35yNig0pbEHGs1dNmj390Y0I7W52YN/P6wPlfhtAGjkGyn6NSKeJLQL7N0RBB3a F96w2LDdzqwJrni0SrgxCORw8CChiaEkK65bu/WohHitE0HChZo4K5bq4pIl0G0l6x7Q 1Qyg== X-Gm-Message-State: ACrzQf3FPgHgWFXoxNAipXpMqLCc3jLLhLHhOYGoHkaTo/JMfMu9uhLX YsTcfjdX3hxCU1zidBgoQUblcghd77Gjbg== X-Google-Smtp-Source: AMsMyM6hS81ym5mgZWKku3MNoEojxodZgzaOHdqx99TUdhb2ywXMl2KznVUZ/UgDwskZ/lO73ZUkQA== X-Received: by 2002:a05:6402:3221:b0:459:61c3:eea0 with SMTP id g33-20020a056402322100b0045961c3eea0mr3541016eda.225.1665044619435; Thu, 06 Oct 2022 01:23:39 -0700 (PDT) Received: from Mini.fritz.box (pd9e36a85.dip0.t-ipconnect.de. [217.227.106.133]) by smtp.gmail.com with ESMTPSA id f17-20020a50ee91000000b00458b41d9460sm5255465edr.92.2022.10.06.01.23.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Oct 2022 01:23:38 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <83bkqpqsr9.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 06 Oct 2022 11:08:10 +0300") References: <83edvlqvxy.fsf@gnu.org> <925e9a8a-3271-615d-0e7e-0710dc871ad1@gmail.com> <83bkqpqsr9.fsf@gnu.org> Date: Thu, 06 Oct 2022 10:23:38 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: 58042@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > A new bug or maybe even nothing. Because we don't have any ideas for > how to solve such a bug in general. Right. I'll close this bug then. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 06 04:24:01 2022 Received: (at control) by debbugs.gnu.org; 6 Oct 2022 08:24:01 +0000 Received: from localhost ([127.0.0.1]:58872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogMAj-0000HD-Gf for submit@debbugs.gnu.org; Thu, 06 Oct 2022 04:24:01 -0400 Received: from mail-ej1-f47.google.com ([209.85.218.47]:43887) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogMAh-0000Gz-4H for control@debbugs.gnu.org; Thu, 06 Oct 2022 04:24:00 -0400 Received: by mail-ej1-f47.google.com with SMTP id a2so2819959ejx.10 for ; Thu, 06 Oct 2022 01:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:subject:from:to:message-id :date:from:to:cc:subject:date; bh=h7Nwspsw5GD0r8PEcPl2VCI5ERhHDGob5ADGfPS4tJ0=; b=RZELtV738GXfTg+lakdIN9F7DdHCYGHwZfkpEr9hFb9cswyxILBGEzAG25Hj6aa8t3 3ioPUlvur30hKLcRjOy7791EuBrEGg4xtcW1twKEpGQbN+z2V9nlYxwWzmh5Bcx/5SyG anWGCqM4f2ylv/36PaJ6XsQkVsAvwmrZBR7dF0MjyPhlHemWeG2GJTLrFQNcfzM/FULE UqxZkpMWW+RuVLPgKa1IMQvx/GK7S+Q27REZ1uwHn3FRxKR2btCyQkxowANQ/qtl/Ty3 EPZsedE7oN3AC9AXRM4DKXsbuG+0sw0zyJiGfqOsXwwPyCBDhAFIB5nM88z37be8uPrR yE1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:subject:from:to:message-id :date:x-gm-message-state:from:to:cc:subject:date; bh=h7Nwspsw5GD0r8PEcPl2VCI5ERhHDGob5ADGfPS4tJ0=; b=X+WEzdCCFMRHkkBwtt2dzyeqCDevjRw1p47xtx5+U6ZcZ1Z96/zRJbkMww2DPo/wFX LF0epH8j23uijBIkXLJIXDSV52YULpxQPKrFLOyF4OwSIvpmqtQr6Tms64g4eRbCMy6x vupm5qe365/+JHn+tUG8BNyp/NHUJP73pja38AFH6fEdIbuF4m95NcqpJfhCdfBMfIlT eVuoHWIVZLo6HKqQj/qwyzPdUjx+FMlm/wmrhs/9fT/7Os3DcVEvvBRY9NYVpiczRTyp beh5uu8ydvECGu5+BnbkGZsgmWoxvoyX67uDE6e3lJ9HQoSEjDXBcSOs6uqYObRS8YnB 2MHw== X-Gm-Message-State: ACrzQf2/Hmjz9DiHaYIQEfipzgQFnvVbPawaRuxuAWVzJNXB/z8i3EzI qIFHH2pk04oQvFIo9NkykWzR0c3xa6BsFA== X-Google-Smtp-Source: AMsMyM5tI4wM//TIdDZ7EpjHp5q8Sv5D4N6strpTiUyEiOYW9KW64NqIFdWozc7B7dKaZJlAfB2Bqw== X-Received: by 2002:a17:907:1b0e:b0:72f:9b43:b98c with SMTP id mp14-20020a1709071b0e00b0072f9b43b98cmr2999647ejc.710.1665044633225; Thu, 06 Oct 2022 01:23:53 -0700 (PDT) Received: from Mini.fritz.box (pd9e36a85.dip0.t-ipconnect.de. [217.227.106.133]) by smtp.gmail.com with ESMTPSA id bm15-20020a170906c04f00b0073c80d008d5sm9792347ejb.122.2022.10.06.01.23.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Oct 2022 01:23:52 -0700 (PDT) Date: Thu, 06 Oct 2022 10:23:51 +0200 Message-Id: To: control@debbugs.gnu.org From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Subject: control message for bug #58042 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) close 58042 29.1 quit From unknown Sat Aug 16 22:46:59 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 03 Nov 2022 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Mon May 08 10:06:11 2023 Received: (at control) by debbugs.gnu.org; 8 May 2023 14:06:11 +0000 Received: from localhost ([127.0.0.1]:41241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pw1VD-0006gZ-8V for submit@debbugs.gnu.org; Mon, 08 May 2023 10:06:11 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18073) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pw1VA-0006gM-V5 for control@debbugs.gnu.org; Mon, 08 May 2023 10:06:09 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 58B258080C; Mon, 8 May 2023 10:06:03 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 431D28025F; Mon, 8 May 2023 10:05:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1683554758; bh=g5UylE9IneBNRWQ36HabO3t/rPPDmBE9WzV6Z2yJV44=; h=From:To:Subject:In-Reply-To:References:Date:From; b=QYKXvPlKvSIvpYUpCFDNhzJhqHeGHz9UVEjnYjuhyXO/hSNwr2YYXhcE+wm6kjPDq DohksjQ4L50bF/yGvx55ieCocRT6Qf7C9GEd5oq3rY3iSETrUvuUBqxv9GE64T3LJx n2dRT5tuNULoilUavOuuAPVeDpHCG6ALa8pZAkCEgWFiSmVVyf1pC/cB7EQEm6HHHH 8tlx3wCGK9XTtTEV8Xs3GdhYvNVWMo8et4niR3+yOUzQy0yrwi5SOF0iqxDI+u+yFY UsiQxzrtB6Hp1tP/NYK9tCjhHk29B3gRpxl/BKcn/Cxt1mb97WCfC8NcVIpOzaE/h9 /1Dln1GBILq1g== Received: from pastel (unknown [45.72.217.176]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id ED4281204BA; Mon, 8 May 2023 10:05:57 -0400 (EDT) From: Stefan Monnier To: control@debbugs.gnu.org Subject: Re: Archived problem report bug#58042 (bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal) In-Reply-To: (GNU bug Tracking System's message of "Mon, 08 May 2023 14:02:02 +0000") Message-ID: References: Date: Mon, 08 May 2023 10:05:55 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.109 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) unarchive 58042 From debbugs-submit-bounces@debbugs.gnu.org Mon May 08 10:08:51 2023 Received: (at 58042) by debbugs.gnu.org; 8 May 2023 14:08:51 +0000 Received: from localhost ([127.0.0.1]:41249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pw1Xm-0006km-Lf for submit@debbugs.gnu.org; Mon, 08 May 2023 10:08:50 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24880) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pw1Xj-0006kR-Mv for 58042@debbugs.gnu.org; Mon, 08 May 2023 10:08:48 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 68820442B87; Mon, 8 May 2023 10:08:42 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3B91C4423D9; Mon, 8 May 2023 10:08:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1683554921; bh=S2Hn2G1/liCG4wiEnMFt7jfL5Gi/p3Na8fuAJc6GouU=; h=Resent-To:Resent-From:Resent-Date:From:To:Cc:Subject:In-Reply-To: References:Date:From; b=EmdgueWr3YrLwX3kTfmhMoanzhDRCc8dCaOI+rGzqxSdwXg66Npi2K6L5nEiq4oEZ rNHu7fgId2/Jbxna8leQk1CYIF/uMVhICtzcBj8I/T5BgVPP2M1B3XbcWMGCfqhHOc 3sSU7Nzy0zKMQt3tJ6f9zQoh/KN6EJBGbOCauOuDT/4RujVDf6qm4WItgpj877sOIt P6XJAIg5yJovJBgtZ/6QC1DTvIkm6zohJIH85fbQ+7VqRTwsM/w7nzDyTJgWF4V1rf PjW/A2+HesWxcT359Q/Crh+v4yL1j3VVKfcPLqAizBM49mld3QpYU5aEVUSFsjEEpr B1FNS1/RfNDDQ== Received: from pastel (unknown [45.72.217.176]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1F85F1204E8; Mon, 8 May 2023 10:08:41 -0400 (EDT) Resent-Message-ID: Resent-To: 58042@debbugs.gnu.org Resent-From: Stefan Monnier Resent-Date: Mon, 08 May 2023 10:08:40 -0400 Received: from mail01.iro.umontreal.ca by mail01.iro.umontreal.ca with LMTP id eHZNGc8AWWR0GAAASs+2LQ (envelope-from ) for ; Mon, 08 May 2023 10:01:51 -0400 Received: from mailscanner.iro.umontreal.ca (pmg1.iro.umontreal.ca [172.31.2.40]) by mail01.iro.umontreal.ca (Postfix) with ESMTPS id 3520D1401A0 for ; Mon, 8 May 2023 10:01:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1683554511; bh=S2Hn2G1/liCG4wiEnMFt7jfL5Gi/p3Na8fuAJc6GouU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=azrJaQ4979d+yul7V/iURvMVt+jKLgJV9oWVY5M320iLYfT+DJ9PkiOwcq84+4dmS G5KmKl1MPTvQlO6+H1LM7ZctPP1LNM+JkSPxhvtqmkf1utpc2zUMh7m/k8OHRjtHk7 lED2acx/ziEaosyBoTGUL3xS1yXAPiCkurcx+ZE+qhI5HlK6+sniK37WNRP0PHiR/Z dZqwq7HpV1He0jYSJaUoK/tpfQCBfEkloWmvWofShJ567Fs1HMbHU7bQf20F+ToCy0 jIciGLg+vaXyw50z82MYZytKEjXV4XgilfzEtt5MUIH9tE+sSdmXAjEThCmeMNghC2 gB1M4hAaYhHXA== Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 13BC0100193; Mon, 8 May 2023 10:01:51 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6AD281001A4; Mon, 8 May 2023 10:01:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1683554509; bh=S2Hn2G1/liCG4wiEnMFt7jfL5Gi/p3Na8fuAJc6GouU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=anB65GzMvJ+xkTlcftVUNNEv59EeS0oBCBNupP7y3yHBlVu3hAGF/S/boxd24NVof t250w0ylZiYy72zXEcxZpu2VvdfecN0vO9+F6AYftSl8BcDvYf/JcuKZMs0KRKARxo ZHnGl7pbfTK2yRv15QkqrieW/ISbCkM3WnR0ixFTXISxy+0xCymr1t4zfv7iWGXNfh XRuZxWWJOBvogzIlJo/yhtN5I2wwX6iPM0Zht69yj2Vo87OirYLsJC3vwj1ntpD7aq pW11TMbl2+qaCouI0rnZDn90XKatikdNPCyUNbzLLl8hOUt8yxVw19meljjVR9f2ri afFx/alFhpatw== Received: from pastel (unknown [45.72.217.176]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E1E3C12024D; Mon, 8 May 2023 10:01:48 -0400 (EDT) From: Stefan Monnier To: Po Lu Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <877d1ewnx0.fsf@yahoo.com> (Po Lu's message of "Wed, 05 Oct 2022 18:43:55 +0800") Message-ID: References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <877d1ewnx0.fsf@yahoo.com> Date: Mon, 08 May 2023 10:01:47 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.501 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DCC_CHECK 1.1 Detected as bulk mail by DCC (dcc-servers.net) DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain FSL_BULK_SIG 0.001 Bulk signature with no Unsubscribe T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: Gerd =?windows-1252?Q?M=F6llmann?= , Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >>> Isn't the -[EmacsView layoutSublayersOfLayer:] the problem? AFAICT from >>> a web search, this is an event handler method that is also called from >>> by the framework? >>> >>> In the olden days, it was a serious error to call into Lisp from an >>> event handler. All bets were off when that happened, not only related >>> to GC. I believe that hasn't changed much. > > Today, event handling code calls Lisp all the time (through safe_call > etc.) That happens in handle_one_xevent, ns_select, et cetera. Really? > It shouldn't affect GC at all because input is blocked for the entire > duration of each GC, except for when finalizers are run after unmarked > objects are sweeped. The problem was not if it's run from within the GC, the problem was what this code does when *it* runs the GC (or other state-changing functions). [ And indeed, the fix Gerd installed was to prevent GC while running pending_signals. But I suspect this is not sufficient because there are other forms of global state that can get messed up. ] In bug#62732 we have a related problem when code run from `maybe_quit` (an atimer in that case) from the regexp engine, and that atimer itself performs a regexp-operation, which messes up the outer regexp engine invocation because the regexp engine is still not re-entrant (in that bug, the problem is the `gl_state` global variable). Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon May 08 21:04:23 2023 Received: (at 58042) by debbugs.gnu.org; 9 May 2023 01:04:23 +0000 Received: from localhost ([127.0.0.1]:41991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwBmA-0006Gk-R1 for submit@debbugs.gnu.org; Mon, 08 May 2023 21:04:23 -0400 Received: from sonic317-33.consmr.mail.ne1.yahoo.com ([66.163.184.44]:46227) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwBm8-0006GS-NR for 58042@debbugs.gnu.org; Mon, 08 May 2023 21:04:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1683594255; bh=MQt0L0EEzeU2lxjTRfU3++AovD1bwGvmRkw9ZHbzPe8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=nFt9aZz+qK+iLLNdMEve21oiFq5wTZQPieWppz936JRotVMmmp3zUzAIXfqoOUg4VS1ztt01/p974WDIK6nvV/B4+MX0Hvu3vEbkHBj9levPb6ToC1mBLTcxVxDwu0D/2BObhVIvpp9jph9HXVqww308nFAUm5XsuUBat/xVQJxFI0jkWfR72HRCNEy6um4KnMMScXH90gHdm+8TyY+BkcWGz2scV5S5liWQkSfrxKqCN9XAGt+zqUeIUxWR1xZ/qntU6oIJ5RXfA8amtf+5QV/+3lC5NF4PAmmQbpKQswFU+IEWW/5bBm0kKsNSp2bf2vakUQpW/VGgX7xVopvmfw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1683594255; bh=2v0X2d4jbBwrWnjZWBLo2U8zgu6LCinvrFYX0fFS3Ib=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=RHMGSGmMvuEx16stuS7oG2GPk286xcSwUvzUuY1rvQ9eR9+vZM/lLCXcvNEy7lgCVyUDRTfwUX0xTdEor7YZ2Q4enqSUEudmS3WQBqPhGwImpST2KepdCOPuxOvUa7wDK/BAu1IFiYhfkY/VyrGMkLXyrFu9FnqmRNnJjKgq68xsgjAzxvAYuf86O0keU0PzPva1HA2OAhkPhD8TUw2PY+PJX+kUzIp5YCQOHSX/a/66wBAB+J8w9K5hj+/31ms1468kLpdjVXk0UnPr7RVszkSkG4g7MxTFm7Z/R+l+qsU5UfrMAbV/6bfcRPKXq+8E13PWtQ+S9wGi24h2o4NDiQ== X-YMail-OSG: NeyjAHwVM1nRPQArBht8XAStNxymagGt7P7r5I7pOldXo9SH6PR76esrnlKqS8D U5gX3EqqRFiEzWJlshiJ2QNqwhzBZgoqCkf7xFhxxle0j2ZseLBsE5mf.NWrcROAufSVNXs6ABDI HKex0J5Bn8HxR1GL0b_jHdmS09ROIZp9V6i3scRSdp7bOqSQ_g.3cvEfESNlqv_EpH8s4uZSZiTJ I91R9TOO0DPK0oDo9CM4PwWtQxdreNoi5woZlFY3Xl5tPLaADkx1Yii9clG2NsNDj8Q0GYzYkgN0 7kATnsdl520ybmmhWogmuna_kk_Fc_sXLBIcEh0aUtH95HtPRUzfOZmrHGTFEvF9BumpqI92cAhO f6_4QNtBpUrEm44G0kBPk1Qpc.aaGMIMzyYVzelyKZCcg4iWiaMIQiU_JruMXpeUXY0y7eVHHKaS b15AcOaL2VVd5A89akOus6SL98oSJmOeVnfAvCd3byURn19QW8MS4p3ae.m5tNZjM6CLmYueWq7C UsQPO_zft512fR55Y.2xIjrKmemrNS5rVY8qnxdVirymf8ixBWadAGqofZeKB3IvbhQI1NagwfpH XGzBqAGsl7SDcPNef_PY71mQcERcLVYlutJhQYpj3PaPWgsJX8.C5_Ejl4LbAHbmKl7kT5kxsCH7 iPoapvLcERDDhLlOFmSuWCnspzXqXr4Tg7hKnQnofyCei2S4caDjWET1BRBm.I5brKRhVv1KwFJq FQkCb_80lhuu02zo3ja35ExdIr5jgXV_IbbqlD_4GEVc3aEMw4NHy_zQNbt4yUBwJwgUO66Qm5bs GkRZjy9.BQWCaEO0Z2zZz_vtFti9zB_Cv1bA49jni_N6fbabWYKdqI.gwpzRyJ.OReI4NKpb.8JF R2EfhhFr0HwZriFnkqJugblbDjWotITc4gKI9OpOkJWciWLz1CA8JbP5wlFUuJ1Dsjf23DYaHvVg hcvfgIoARJZ8eLr.d_j3Obh4RFcdoavb16cFk2MNSQ_Ffcu1xZxkw2AwPs2ZtBeS46NDNOrTp4c3 NIqi.MmBIZcBvJnWaRNRl5LqjvhJ4jdIJ.9nyvIDYrA7p2eFsFdcW7HIDYqWbqp7__UsE9tPBy_j SRuw3ij7eYKdHi_eq_P11P7lomACOHYfTKJ1jP125cLc0m8M2xIbjUE3IA5uyXogKL7VV2QGhme. eoHJqscQ2BNhCpCF0JRf7QnXbs3CLgSiK2j99YEl3tNE6jGhxaEsf7SrzUIbfpEjHufWOuJ6qtup g2kpWE9VpeXTyGI1Cwt2eakTqR2M1EwvdnRblz5Rwf4Rwpa9nnF8eAPRMRbK0SuKk01D98LpArpw HoJ0Vbv1Gxqv6OwljwES9CzCYnfO1m2ZsSLP_1uqUaXNnxxbLLANlDmtjjtK_JCjeps1ZC0pnO_V GunPqG.CZrvfLBN9iTEVua0jNpgejxS6YENa6lpJTDvBXfjucpZh4S2.mHwk69aH9VvUTbtgrCPS qGQP0uVOhBudkGIn2Gzi1T8c5dzhH3uDQg7cfDWlBFw9MoVGFqOSDEjCxgwkMZf70EwV7NCHNR68 OZnbJaGheqpavtivciZekNd4MyVPrT4QPggDlHM2kQ_0yWmfPeutZtNY2pLWXxekM7dP8iOpm_xh V_JfSFyJpDxFSkuKgcL197GCA2snnWOZkEZ6rc9y3_OZIG77iGxieYm7nIRyFJCn5yk5MIyzO.Ex HWtc0WAwO.rZFZDDdJxcySCJkUtaqRmpZd82YH68rORsRr0kWO.6nDskqU8TLdmUlyinPBpJpGhO wR2C1saS96XQTxGu.SxBDw0hbzAra4LwnjVHERAC72ubGqRYQGGyeQWBcMgWvAdDn5LQPh2CV0Lz n._.P5SjfSA.H4hjBWzLoF28UCCg4rtRKh3IFmmUeMOLWjBrAhvEkHr50Xwb.sVUS1nX8LLX.BEk pGxxm0TE34JvAsemCnIO.GY.4fjkQdDAeJgJoFccBwSAugHiAZK2M8pEovgvGV4FQxS_XZ9_TzA2 pEYrOpr_vLVLMXXrZL_549DEg7URll3DKkHvQIDhUTY0CTqwo4fZ6tbZCotXwjoSQ9MM_LmmYkUf IP4fpuWoW5L_XXNQ6KIx3Z.XkrYFAHHZ5rB..VkBDVgF9q6lntE_FonZ23pENbOG1Tqskfb686QR twiq4kYCWy3JYU7b13dZBUFuhrOAFSGgsqQClx9HrPBdLhoZKXFSBrNtxhGXKiHTLQgc7eipd_Va UEwhg7WK91y12PrkzjxdcK01MP8lPuATubXLeyRrArdexOC8mgMTIfwsnMIB0 X-Sonic-MF: X-Sonic-ID: 21279938-e0d4-43e8-9f04-aa1676310eb8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Tue, 9 May 2023 01:04:15 +0000 Received: by hermes--production-sg3-6d6fb994f6-c7twq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d8f47ff5d11a0c6e9de56f77145da67e; Tue, 09 May 2023 01:04:08 +0000 (UTC) From: Po Lu To: Stefan Monnier Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: (Stefan Monnier's message of "Mon, 08 May 2023 10:01:47 -0400") References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <877d1ewnx0.fsf@yahoo.com> Date: Tue, 09 May 2023 09:04:03 +0800 Message-ID: <87o7muiad8.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21417 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 983 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58042 Cc: Gerd =?utf-8?Q?M=C3=B6llmann?= , Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > Really? Yes. > The problem was not if it's run from within the GC, the problem was what > this code does when *it* runs the GC (or other state-changing functions). > [ And indeed, the fix Gerd installed was to prevent GC while running > pending_signals. But I suspect this is not sufficient because there > are other forms of global state that can get messed up. ] > > In bug#62732 we have a related problem when code run from `maybe_quit` > (an atimer in that case) from the regexp engine, and that atimer > itself performs a regexp-operation, which messes up the outer regexp > engine invocation because the regexp engine is still not re-entrant (in > that bug, the problem is the `gl_state` global variable). bug#62732? That's: 29.0.60; uniquify-trailing-separator-p affects any buffer whose name matches a dir in CWD I don't see how it's related to reentrant use of the regexp engine. BTW, which atimer is it? From debbugs-submit-bounces@debbugs.gnu.org Mon May 08 22:25:29 2023 Received: (at 58042) by debbugs.gnu.org; 9 May 2023 02:25:29 +0000 Received: from localhost ([127.0.0.1]:42048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwD2f-0000ET-Kl for submit@debbugs.gnu.org; Mon, 08 May 2023 22:25:29 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwD2e-0000EF-6z for 58042@debbugs.gnu.org; Mon, 08 May 2023 22:25:28 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E2043442E95; Mon, 8 May 2023 22:25:22 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 90138442E8F; Mon, 8 May 2023 22:25:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1683599121; bh=HNsycMR+xBPz/HG0eIcZLFujYqjG+qLrQqewF4hNpdc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Hjx4yzmWvsE0YSx1AEFjPm+a9vzPgu2Gi0q4D7e5W7j1xflEpJXlitxIttmc+trtw LxEoCT3kwycqqf5XlfcOd27VnPnMo4t60W/oDkPd71aKCXli0uwNnuCEMF45qWs025 nEiA7UqJlrtotXeETYMrdsv9UU5qVqo1rX8V3oZAfuYKFaPiREcWjuaDHDfodLCWCI UQgAI5Ju9l/w4mMxwGub2VM841nssqUR6ULZ+Q7tmXHrv2mKSsfemaeCtV4wNgU+65 ZSJFxp5TIW4T3rOhhCbBabVZGk+Dothq0vFNYYmU8kdRr8z4MQiH2GJOTvTVaWjtop YHp7Sygt7OS5Q== Received: from pastel (unknown [45.72.217.176]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 34F511208DC; Mon, 8 May 2023 22:25:21 -0400 (EDT) From: Stefan Monnier To: Po Lu Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal In-Reply-To: <87o7muiad8.fsf@yahoo.com> (Po Lu's message of "Tue, 09 May 2023 09:04:03 +0800") Message-ID: References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <877d1ewnx0.fsf@yahoo.com> <87o7muiad8.fsf@yahoo.com> Date: Mon, 08 May 2023 22:25:11 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.052 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: Gerd =?windows-1252?Q?M=F6llmann?= , Eli Zaretskii , 58042@debbugs.gnu.org, Alan Third X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Really? > Yes. Damn! I thought at least `handle_one_xevent` was "ELisp-clean". >> In bug#62732 we have a related problem when code run from `maybe_quit` >> (an atimer in that case) from the regexp engine, and that atimer >> itself performs a regexp-operation, which messes up the outer regexp >> engine invocation because the regexp engine is still not re-entrant (in >> that bug, the problem is the `gl_state` global variable). > > bug#62732? That's: Hmm... not sure how I ended up writing this. I meant bug#63253 Sorry 'bout that. > I don't see how it's related to reentrant use of the regexp engine. > BTW, which atimer is it? The atimer for `with-delayed-message`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue May 09 01:30:03 2023 Received: (at 58042) by debbugs.gnu.org; 9 May 2023 05:30:03 +0000 Received: from localhost ([127.0.0.1]:42245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwFv5-0006Dw-1d for submit@debbugs.gnu.org; Tue, 09 May 2023 01:30:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwFv3-0006Db-TB for 58042@debbugs.gnu.org; Tue, 09 May 2023 01:29:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pwFux-0005Wp-Po; Tue, 09 May 2023 01:29:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=jYshvT998DZ1lHqnOaL5+8WOFB8tVN7yolXpwpN6F9Q=; b=JF7a6YVHoTJYyTXzwgiS JzkBuBxRFvbNCfW8u6cbzSLlwBgR4RRITny7rwlrL+NW2h/sbrTY9N15HSnb5nLFzPMzfOY3ThU+U 5nIqkfpsFa5VuVrsFf4hE9oc5DbuM0WSpbzfAEMnai+30w+e3A8EjDEYvbDfDp/U+9tO0xsOBaMrP ITeuN1nefRDrIGcpb2jQiUMGCc+c2/h7WNaSz+rtYfznoVydX0mnWjFU+hmSn9irGQgJlMGtBcZN1 KKRQ7b/I7H0AdSmmILO0yMS4C4zTTsDUlAb2Q++0uwTIDmKRREE4ePezHPlGdhd9p/FXfvZfF5CRc Co6xkFPP0IkWGg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pwFuw-0006P0-N4; Tue, 09 May 2023 01:29:43 -0400 Date: Tue, 09 May 2023 08:30:45 +0300 Message-Id: <83mt2eax6i.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <87o7muiad8.fsf@yahoo.com> (message from Po Lu on Tue, 09 May 2023 09:04:03 +0800) Subject: Re: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal References: <83edvnv965.fsf@gnu.org> <83pmf6u76i.fsf@gnu.org> <83mtaau43p.fsf@gnu.org> <83ilkytyif.fsf@gnu.org> <877d1ewnx0.fsf@yahoo.com> <87o7muiad8.fsf@yahoo.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58042 Cc: gerd.moellmann@gmail.com, alan@idiocy.org, 58042@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Po Lu > Cc: Gerd Möllmann , Eli > Zaretskii , > 58042@debbugs.gnu.org, Alan Third > Date: Tue, 09 May 2023 09:04:03 +0800 > > Stefan Monnier writes: > > > Really? > > Yes. > > > The problem was not if it's run from within the GC, the problem was what > > this code does when *it* runs the GC (or other state-changing functions). > > [ And indeed, the fix Gerd installed was to prevent GC while running > > pending_signals. But I suspect this is not sufficient because there > > are other forms of global state that can get messed up. ] > > > > In bug#62732 we have a related problem when code run from `maybe_quit` > > (an atimer in that case) from the regexp engine, and that atimer > > itself performs a regexp-operation, which messes up the outer regexp > > engine invocation because the regexp engine is still not re-entrant (in > > that bug, the problem is the `gl_state` global variable). > > bug#62732? He meant bug#63253, I think. From unknown Sat Aug 16 22:46:59 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 06 Jun 2023 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator