all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Vasilij Schneidermann <v.schneidermann@gmail.com>
Cc: 29789@debbugs.gnu.org
Subject: bug#29789: 25.1; Emacs blocks user input when using visual-fill-column in wide	terminals
Date: Thu, 21 Dec 2017 07:01:39 +0200	[thread overview]
Message-ID: <926C5E01-36F9-48EC-ADC3-6A443A6D8D3B@gnu.org> (raw)
In-Reply-To: <838tdwoiop.fsf@gnu.org>

On December 21, 2017 5:37:10 AM GMT+02:00, Eli Zaretskii <eliz@gnu.org> wrote:
> > 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.

Forget it, I've succeeded in reproducing this.  The reason I couldn't before is because most themes do nothing if the terminal supports less than 89 colors (looks like their authors are just copying that condition from one another for no good reason), so I needed to find a theme which does work with fewer colors.





  reply	other threads:[~2017-12-21  5:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-20 19:28 bug#29789: 25.1; Emacs blocks user input when using visual-fill-column in wide terminals Luis Gerhorst
2017-12-20 20:29 ` Eli Zaretskii
2017-12-20 20:45   ` Luis Gerhorst
2017-12-20 21:35 ` Vasilij Schneidermann
2017-12-21  3:37   ` Eli Zaretskii
2017-12-21  5:01     ` Eli Zaretskii [this message]
2017-12-21 17:49       ` Eli Zaretskii
2017-12-21 17:52         ` Luis Gerhorst

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=926C5E01-36F9-48EC-ADC3-6A443A6D8D3B@gnu.org \
    --to=eliz@gnu.org \
    --cc=29789@debbugs.gnu.org \
    --cc=v.schneidermann@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.