bug#25279: Fwd: bug#25279: 26.0.50; Slowdown/crash on certain characters

[Richard Copley <rcopley@gmail.com>]

I inadvertently replied to Eli without CC'ing the bug.
Forwarded message for the record:

On 27 December 2016 at 07:21, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Mon, 26 Dec 2016 21:21:57 +0000
>> Cc: 25279@debbugs.gnu.org
>>
>> > A crash shouldn't happen in any case, so if you can show a recipe and
>> > a backtrace, maybe this could be fixed.
>> >
>> > Thanks.
>>
>> Reproducing the slowness and high CPU consumption is easy.
>>
>> The "crash" I referred to is probably better termed a "hang" (as
>> far as I can see an indefinite one), sorry. I don't know a simple
>> recipe, but if you use Emacs in this state for long enough, it
>> usually hangs eventually.
>
> Is it a hang, or just some long and very busy loop?

If it's a long busy loop, it's very very long.

> E.g., if you set
> garbage-collection-messages to a non-nil value, do you see periodic
> announcements of GC during the "hang"?

No! (I was surprised.) Currently the message area says "quit".
(I don't know whether it's always "quit".)

>  And if you go for a coffee,
> does Emacs eventually recover and starts responding again?

I've tried coffee, beer, even a good night's sleep, but all to no effect.

> What if
> you type M-< or M-> to force the problematic characters out of the
> displayed portion of the buffer -- does Emacs recover then?

No apparent effect.

>> Recipe:
>> Uninstall Symbola (but perhaps other font changes are required).
>
> It isn't easy to uninstall fonts from a running system, because they
> are usually in use by some application.  So reproducing this will be
> hard for me, as I have Symbola installed everywhere.  I will try to
> find such a system, but no promises.
>
>> Below are C call stacks obtained from a hung emacs process
>> by attaching gdb to it.
>
> Is it possible for you to try to figure out what is the looping stack
> frame, by following the advice in etc/DEBUG, under "If the symptom of
> the bug is that Emacs fails to respond"?

This is the hanging function / stack frame:

#0  0x00007ffc3c011184 in win32u!NtUserMessageCall () from
C:\WINDOWS\System32\win32u.dll
#1  0x00007ffc3dbe116d in USER32!SendMessageW () from
C:\WINDOWS\System32\user32.dll
#2  0x00007ffc3dbe83e5 in USER32!SendMessageA () from
C:\WINDOWS\System32\user32.dll
#3  0x000000040020cf33 in w32_set_vertical_scroll_bar ()
#4  0x0000000400063938 in redisplay_window ()
#5  0x0000000400067e86 in redisplay_window_0 ()
#6  0x0000000400175951 in internal_condition_case_1 ()
#7  0x0000000400026eea in redisplay_windows ()
#8  0x0000000400051669 in redisplay_internal ()
#9  0x00000004000ed795 in read_char ()
#10 0x00000004000f0790 in read_key_sequence.constprop ()
#11 0x00000004000f26eb in command_loop_1 ()
#12 0x0000000400175809 in internal_condition_case ()
#13 0x00000004000e1614 in command_loop_2 ()
#14 0x00000004001756f7 in internal_catch ()
#15 0x00000004000e15c9 in command_loop ()
#16 0x00000004000e62c4 in Frecursive_edit ()
#17 0x000000040026e699 in main ()

That's with "-O3". There's something up with my environment that's
stopping me from rebuilding Emacs. l'll get back to you when I have
a backtrace with "-Og -g -ggdb".

>> Possibly a clue:
>> While I had the hung emacs process stopped in GDB I started a
>> new Emacs process to edit this email and the new Emacs was
>> also horribly slow! When I killed the process in the debugger,
>> the new Emacs recovered to normal speed.
>
> Attaching a debugger to Emacs built from the master branch causes such
> problems due to the low-level keyboard hook in Emacs.  (We avoid that
> problem when Emacs is started from GDB to begin with.)  So I don't
> think this is relevant to the issue at hand.
>
> Thanks.