bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Po Lu <luangruo@yahoo.com>,  Alan Third <alan@idiocy.org>,
>   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.