From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal Date: Wed, 05 Oct 2022 11:00:00 +0200 Message-ID: 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: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21774"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 58042@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 05 11:01:49 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1og0Hk-0005WH-D0 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Oct 2022 11:01:48 +0200 Original-Received: from localhost ([::1]:58148 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1og0Hj-0004pA-1M for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Oct 2022 05:01:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53972) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og0H0-0004ov-Ne for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2022 05:01:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56769) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1og0H0-0000iF-Cw for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2022 05:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1og0H0-0002za-2L for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2022 05:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Oct 2022 09:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58042 X-GNU-PR-Package: emacs Original-Received: via spool by 58042-submit@debbugs.gnu.org id=B58042.166496041211418 (code B ref 58042); Wed, 05 Oct 2022 09:01:02 +0000 Original-Received: (at 58042) by debbugs.gnu.org; 5 Oct 2022 09:00:12 +0000 Original-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 Original-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 Original-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) Original-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) In-Reply-To: ("Gerd =?UTF-8?Q?M=C3=B6llmann?="'s message of "Wed, 05 Oct 2022 09:34:30 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:244498 Archived-At: 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!