bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Po Lu
Subject: bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal
Date: Wed, 05 Oct 2022 19:10:02 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux)

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> 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!

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);
     }
 
+  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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]