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

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

bug#29789: 25.1; Emacs blocks user input when using visual-fill-column i


From: Eli Zaretskii
Subject: bug#29789: 25.1; Emacs blocks user input when using visual-fill-column in wide terminals
Date: Thu, 21 Dec 2017 05:37:10 +0200

> Date: Wed, 20 Dec 2017 22:35:30 +0100
> From: Vasilij Schneidermann <v.schneidermann@gmail.com>
> 
> I can reproduce this on Arch Linux, with Emacs master and Termite.  I've
> tried making a full backtrace in gdb, let me know if there's anything
> else I can do to help debugging this issue.

Thanks.

> Thread 1 "emacs" received signal SIGTSTP, Stopped (user).
> 0x00007f5ccb9f9b47 in kill () from /usr/lib/libc.so.6
> Continuing.
> 
> Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, 
>     backtrace_limit=40) at emacs.c:364
> 364   {
> #0  0x0000000000569e7a in terminate_due_to_signal (sig=6, backtrace_limit=40)
>     at emacs.c:364
> #1  0x00000000005919c8 in emacs_abort () at sysdep.c:2426
> #2  0x00000000005829d2 in handle_interrupt (in_signal_handler=true)
>     at keyboard.c:10501
> #3  0x0000000000582795 in handle_interrupt_signal (sig=2) at keyboard.c:10371
> #4  0x0000000000590f88 in deliver_process_signal (sig=2, handler=0x582743 
> <handle_interrupt_signal>) at sysdep.c:1709
> #5  0x00000000005827b4 in deliver_interrupt_signal (sig=2) at keyboard.c:10378
> #6  0x00007f5ccc8a9da0 in <signal handler called> () at 
> /usr/lib/libpthread.so.0
> #7  0x00000000005083c0 in append_glyph (it=0x7ffcb39bc150) at term.c:1476
> #8  0x00000000005087d5 in produce_glyphs (it=0x7ffcb39bc150) at term.c:1584
> #9  0x00000000004722e7 in extend_face_to_end_of_line (it=0x7ffcb39bc150)
>     at xdisp.c:20318
> #10 0x00000000004773eb in display_line (it=0x7ffcb39bc150, cursor_vpos=3)
>     at xdisp.c:21740
> #11 0x0000000000469edf in try_window (window=XIL(0xd7f9a5), pos=..., flags=1)
>     at xdisp.c:17610
> #12 0x000000000046799c in redisplay_window (window=XIL(0xd7f9a5), 
> just_this_one_p=false) at xdisp.c:17057
> #13 0x0000000000460734 in redisplay_window_0 (window=XIL(0xd7f9a5))
>     at xdisp.c:14814
> #14 0x000000000061975f in internal_condition_case_1 (bfun=0x4606f2 
> <redisplay_window_0>, arg=XIL(0xd7f9a5), handlers=XIL(0xd6bf13), 
> hfun=0x4606ba <redisplay_window_error>) at eval.c:1356
> #15 0x000000000046068c in redisplay_windows (window=XIL(0xd7f9a5)) at 
> xdisp.c:14794
> #16 0x000000000045f4b8 in redisplay_internal () at xdisp.c:14283
> #17 0x000000000045ff5e in redisplay_preserve_echo_area (from_where=2)
>     at xdisp.c:14613
> #18 0x0000000000426d03 in Fredisplay (force=XIL(0)) at dispnew.c:5828
> #19 0x000000000061d47a in funcall_subr (subr=0x951720 <Sredisplay>, 
> numargs=0, args=Quit
> #0  0x0000000000569e7a in terminate_due_to_signal (sig=6, backtrace_limit=40)
>     at emacs.c:364
> #1  0x00000000005919c8 in emacs_abort () at sysdep.c:2426
> #2  0x00000000005829d2 in handle_interrupt (in_signal_handler=true)
>     at keyboard.c:10501
>         c = 121 'y'
> #3  0x0000000000582795 in handle_interrupt_signal (sig=2) at keyboard.c:10371
>         terminal = 0x12cfe40 <bss_sbrk_buffer+6086848>
> #4  0x0000000000590f88 in deliver_process_signal (sig=2, handler=0x582743 
> <handle_interrupt_signal>) at sysdep.c:1709
>         old_errno = 22
>         on_main_thread = true
> #5  0x00000000005827b4 in deliver_interrupt_signal (sig=2) at keyboard.c:10378
> #6  0x00007f5ccc8a9da0 in <signal handler called> () at 
> /usr/lib/libpthread.so.0
> #7  0x00000000005083c0 in append_glyph (it=0x7ffcb39bc150) at term.c:1476
>         glyph = 0x7f5cd4622fd0
>         end = 0x7f5cd4622fd0
>         i = 0

This says Emacs got SIGINT and then aborted.  Did you type C-g more
then once and then answered YES to the question whether to abort and
dump core?

> #8  0x00000000005087d5 in produce_glyphs (it=0x7ffcb39bc150) at term.c:1584
> #9  0x00000000004722e7 in extend_face_to_end_of_line (it=0x7ffcb39bc150)
>     at xdisp.c:20318

The "hang" sounds like some infloop in redisplay.  It will be helpful
if instead of trying to interrupt Emacs with C-g, you could attach the
debugger, produce a backtrace from the place where Emacs was caught,
and then use the technique described in etc/DEBUG under "If the
symptom of the bug is that Emacs fails to respond", starting at "If
Emacs is in an infinite loop", to find out where it loops.

Also, I need to know what version of Emacs is that, to match line
numbers in the backtrace to the sources.





reply via email to

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