bug#59183: 29.0.50; emacs_abort () at sysdep.c:2313

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> #0  terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:421
>> #1  0x000055555579def5 in emacs_abort () at sysdep.c:2313
>> #2  0x00005555559324d6 in itree_iterator_start (tree=0x555556e65850, 
>> begin=359683, end=592913, order=ITREE_ASCENDING, file=0x5555559eca4f 
>> "buffer.c", line=2982) at itree.c:1161
>> #3  0x00005555557ae9ef in overlays_in (beg=359683, end=359684, extend=false, 
>> vec_ptr=0x7fffffff18c0, len_ptr=0x7fffffff1910, empty=false, trailing=true, 
>> next_ptr=0x0) at buffer.c:2982
>> #4  0x00005555557aebed in overlays_at (pos=359683, extend=false, 
>> vec_ptr=0x7fffffff18c0, len_ptr=0x7fffffff1910, next_ptr=0x0) at 
>> buffer.c:3035
>> #5  0x0000555555646226 in note_mouse_highlight (f=0x5555590388f0, x=181, 
>> y=321) at xdisp.c:35144
>> #6  0x000055555570b846 in x_note_mouse_movement (frame=0x5555590388f0, 
>> event=0x7fffffff1f20, device=XIL(0x5555563b5cd4)) at xterm.c:14137
>> #7  0x000055555571ab35 in handle_one_xevent (dpyinfo=0x55555a326240, 
>> event=0x7fffffff2380, finish=0x7fffffff2370, hold_quit=0x7fffffff24a0) at 
>> xterm.c:22381
>> #8  0x000055555571f577 in XTread_socket (terminal=0x5555572511a0, 
>> hold_quit=0x7fffffff24a0) at xterm.c:24551
>> #9  0x000055555577d39a in gobble_input () at keyboard.c:7368
>> #10 0x000055555577d997 in handle_async_input () at keyboard.c:7599
>> #11 0x000055555577d9b6 in process_pending_signals () at keyboard.c:7613
>> #12 0x00005555558580cb in probably_quit () at eval.c:1661
>> #13 0x000055555586383d in maybe_quit () at lisp.h:3684
>> #14 0x000055555586ac7c in Fassq (key=XIL(0x5d00), alist=XIL(0x5555594ef1f3)) 
>> at fns.c:1931
>> #15 0x000055555590c41d in lookup_char_property (plist=XIL(0x555560375da3), 
>> prop=XIL(0x5d00), textprop=false) at intervals.c:1735
>> #16 0x00005555557b1dc8 in Foverlay_get (overlay=XIL(0x555560371dcd), 
>> prop=XIL(0x5d00)) at buffer.c:3934
>> #17 0x0000555555911dc1 in get_char_property_and_overlay 
>> (position=make_fixnum(359631), prop=XIL(0x5d00), object=XIL(0x55555e02d465), 
>> overlay=0x7fffffff2768) at textprop.c:649
>
> Stefan, I think we must lift the restriction of "only one itree
> iteration at a time", otherwise we will keep bumping into situations
> like this one.  It isn't hard to imagine other cases where some code
> wants to look up overlays while some of the callers is in the middle
> of something similar; handling the mouse-highlight is just one such
> example.  We never had restrictions in Emacs on simultaneous multiple
> read-only access to overlays, and it makes no sense to introduce such
> restrictions now.
>
> This has to be fixed before Emacs 29.

+1.  I just hit this bug as well.

Would someone please sum up why itree iteration is not reentrant right
now?

TIA.