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

[Richard Copley]

On 27 December 2016 at 13:47, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Tue, 27 Dec 2016 13:36:52 +0000
>>
>> After scrolling up and down with and moving point around like crazy (to
>> try to trigger the bug), Emacs can temporarily stop responding while it
>> catches up (there are, as you deduced, a lot of garbage collections),
>> but doesn't hang for a long time.
>>
>> But pressing C-g can cause the indefinite hang in SendMessage seen
>> above.
>
> How many threads are in the program when the hang happens?

6, according to an earlier message in this bug.

> Is the
> input thread still running?  It should be stuck in w32_msg_pump or
> w32_wnd_proc.

Sounds like Thread 3 from that earlier message.

Thread 3 (Thread 8808.0x2bfc):
#0  0x00007ffc3eb69844 in ntdll!ZwWaitForAlertByThreadId () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ffc3eaefa87 in ntdll!RtlpUnWaitCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x00007ffc3eaef98e in ntdll!RtlpUnWaitCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#3  0x00007ffc3eaef81f in ntdll!RtlpUnWaitCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x00007ffc3eaf0ce4 in ntdll!RtlEnterCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x00007ffc3eaf0c10 in ntdll!RtlEnterCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x0000000400216a9b in post_msg ()
#7  0x00000004001f1920 in post_character_message ()
#8  0x00000004001fc2b6 in w32_wnd_proc ()
#9  0x00007ffc3dbe1c24 in USER32!CallWindowProcW () from
C:\WINDOWS\System32\user32.dll
#10 0x00007ffc3dbe156c in USER32!DispatchMessageW () from
C:\WINDOWS\System32\user32.dll
#11 0x00000004001f9dc3 in w32_msg_pump.isra ()
#12 0x00000004001fa430 in w32_msg_worker ()
#13 0x00007ffc3c038364 in KERNEL32!BaseThreadInitThunk () from
C:\WINDOWS\System32\kernel32.dll
#14 0x00007ffc3eb270d1 in ntdll!RtlUserThreadStart () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#15 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

> The backtrace you show seems to say that SendMessage doesn't return,
> which might mean the thread it is sending the message to is either
> dead or not responding.  That thread is the input thread.

Maybe a deadly embrace then. I'll research how to ask GDB about the
state of kernel sync objects.
Any tips welcome.