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

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

bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs


From: Michael Welsh Duggan
Subject: bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs
Date: Thu, 08 Apr 2021 13:11:34 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> Lisp Backtrace:
>> "window-list-1" (0xffffbfa0)
>> "replace-buffer-in-windows" (0xffffc4a8)
>> "kill-buffer" (0xffffc710)
>> 0x571d80f8 PVEC_COMPILED
>> "substitute-command-keys" (0xffffd3d8)
>> "command-error-default-function" (0xffffd628)
>> "apply" (0xffffd7e8)
>> 0xf2c1d0e8 PVEC_COMPILED
>
> This seems to indicate that kill-buffer is called by
> substitute-command-keys, in which case the buffer in question is a
> temporary buffer.  Can you verify that by looking at the buffer's name
> in frame #13:
>
>> #13 0x0000555555758e6d in Fkill_buffer
>> (buffer_or_name=XIL(0x5555571d7ced)) at
>> ../../master/src/buffer.c:1830
>>         buffer = XIL(0x5555571d7ced)
>>         b = 0x5555571d7ce8
>>         tem = XIL(0x555555753673)
>>         m = 0x7fffffffc5f0

As expected, it is " *temp*".  This time I've kept the session around.

>> Once again, the state triggered when, due to the VPN state changing, a
>> background gnus demon hung trying to fetch mail.  The trigger was me
>> hitting C-g twice rapidly in succession to regain interactivity.
>> 
>> Can anyone recommend a means to check if this my theory is true?  Does
>> list_windows() need to be protected against quit?
>
> Set a breakpoint in 'quit' and disable it.  Set another breakpoint at
> entry to 'window_list' that enables the breakpoint in 'quit', then
> another breakpoint at exit which disables the breakpoint in 'quit'.
> Then wait for the breakpoint in 'quit' to break during your recipe.
>
> Perhaps also do the same with a breakpoint in Fthrow.

I hit the breakpoint in quit.  It looks like Fnconc uses FOR_EACH_TAIL,
which uses FOR_EACH_TAIL_INTENAL, which calls maybe_quit.  The question
in my mind now is whether block/unblock_input belongs in window_list or
in Fnconc.

Thread 4.1 "emacs" hit Breakpoint 8, quit () at ../../master/src/eval.c:1660
1660      return signal_or_quit (Qquit, Qnil, true);
(gdb) bt
#0  quit () at ../../master/src/eval.c:1660
#1  0x00005555557f9a27 in process_quit_flag () at ../../master/src/eval.c:1607
#2  0x00005555557f9a6a in maybe_quit () at ../../master/src/eval.c:1627
#3  0x000055555580eb65 in Fnconc (nargs=2, args=0x7fffffffb910)
    at ../../master/src/fns.c:2783
#4  0x000055555580ea3b in nconc2
    (s1=XIL(0x5555573e73a3), s2=XIL(0x5555573e73c3))
    at ../../master/src/fns.c:2759
#5  0x000055555564b2db in window_list () at ../../master/src/window.c:2578
#6  0x00005555555eb138 in prepare_menu_bars ()
    at ../../master/src/xdisp.c:12717
#7  0x00005555555f2a3c in redisplay_internal ()
    at ../../master/src/xdisp.c:15668
#8  0x00005555555f48f2 in redisplay_preserve_echo_area (from_where=8)
    at ../../master/src/xdisp.c:16385
#9  0x00005555557393fa in detect_input_pending_run_timers (do_display=true)
    at ../../master/src/keyboard.c:10308
#10 0x0000555555869789 in wait_reading_process_output
    (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), 
wait_proc=0x0, just_wait_proc=0) at ../../master/src/process.c:5657
#11 0x0000555555728ed2 in kbd_buffer_get_event
    (kbp=0x7fffffffd428, used_mouse_menu=0x7fffffffda6f, end_time=0x0)
    at ../../master/src/keyboard.c:3869
#12 0x0000555555723ba7 in read_event_from_main_queue
    (end_time=0x0, local_getcjmp=0x7fffffffd800, 
used_mouse_menu=0x7fffffffda6f) at ../../master/src/keyboard.c:2159
#13 0x0000555555723f25 in read_decoded_event_from_main_queue
    (end_time=0x0, local_getcjmp=0x7fffffffd800, prev_event=XIL(0), 
used_mouse_menu=0x7fffffffda6f) at ../../master/src/keyboard.c:2223
#14 0x0000555555725ee8 in read_char
    (commandflag=1, map=XIL(0x55555730fcb3), prev_event=XIL(0), 
used_mouse_menu=0x7fffffffda6f, end_time=0x0) at 
../../master/src/keyboard.c:2833
#15 0x00005555557375dc in read_key_sequence
    (keybuf=0x7fffffffdc70, prompt=XIL(0), dont_downcase_last=false, 
can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false)
    at ../../master/src/keyboard.c:9491
#16 0x0000555555721412 in command_loop_1 () at ../../master/src/keyboard.c:1353
#17 0x00005555557f9424 in internal_condition_case
    (bfun=0x555555720f96 <command_loop_1>, handlers=XIL(0x90), 
hfun=0x5555557205b9 <cmd_error>) at ../../master/src/eval.c:1439
#18 0x0000555555720b86 in command_loop_2 (ignore=XIL(0))
    at ../../master/src/keyboard.c:1094
#19 0x00005555557f8834 in internal_catch
    (tag=XIL(0xd9e0), func=0x555555720b59 <command_loop_2>, arg=XIL(0))
    at ../../master/src/eval.c:1189
#20 0x0000555555720b25 in command_loop () at ../../master/src/keyboard.c:1073
#21 0x00005555557200a2 in recursive_edit_1 ()
    at ../../master/src/keyboard.c:720
#22 0x0000555555720299 in Frecursive_edit () at ../../master/src/keyboard.c:789
#23 0x000055555571c17e in main (argc=2, argv=0x7fffffffe168)
    at ../../master/src/emacs.c:2050

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)


-- 
Michael Welsh Duggan
(mwd@cert.org)





reply via email to

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