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

[Richard Copley <rcopley@gmail.com>]

On 27 December 2016 at 14:15, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Tue, 27 Dec 2016 14:06:27 +0000
>> Cc: 25279@debbugs.gnu.org
>>
>> >> 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.
>
> I think I see what's happening: it's a deadlock.  When you type C-g,
> the input thread (which receives all keyboard input from Windows),
> sets the quit-flag, then attempts to send the C-g character to the
> main thread.  To send the message, it tries to enter critical section,
> and waits for it.  Meanwhile, the main thread tries to tell the input
> thread to draw the scroll bar, and calls SendMessage for that.
> SendMessage waits for the input thread to receive the message, but the
> input thread is stuck waiting for the main thread to exit the critical
> section.

Great! So we should enter the same critical section in the input thread
before calling SendMessage.

(I bet it's not that simple. I'm just trying to join in the fun.)