Subject: bug#12832: 24.3.50; Emacs lockup when idle

From: Andy Moreton <[email-masked]>
Date: Tue, 13 Nov 2012 16:00:30 +0000

On 13/11/2012 15:16, Eli Zaretskii wrote:
>> Date: Tue, 13 Nov 2012 14:25:30 +0000
>> From: Andy Moreton <[email-masked]>
>> CC: Dani Moncayo <[email-masked]>, [email-masked],
>>  [email-masked]
>>
>> Correct - I've done a clean bootstrap using 4.7.0, and I see this problem on
>> both trunk and emacs-24 branches.
>>
>> Looking emacs-24 (r110863) with Process Explorer:
>>
>> 212412   emacs.exe+0x32291              State:  Wait:DelayExecution
>> 212616   emacs.exe+0x148efe             State:  Wait:Suspended
>> 212604   emacs.exe+0x142350             State:  Wait:WrUserRequest
>> 236140   RPCRT4.dll!ThreadStartRoutine  State:  Wait:WrQueue
>>
>> I tried suspending and then resuming each thread in turn from Process
>> Explorer. Resuming thread 212604 unblocked emacs and it started working again.
>
> Was that the only thread whose resumption unlocks Emacs?  If so, can
> you find out what thread was that?  Process Explorer can show that
> call-stack, and you should be able to find out what functions were

I tried to get call stacks from process Explorer, but that made it die :-(

The fatc that thread 236140 is at ThreadStartRoutine makes me wonder if this 
is related to the perils of DllMain (i.e. the loader lock).

> If you attach GDB, do you again see garbled backtrace, like in the
> original report?  Or do you see something more informative?

Sorry, I don't have the original process running any more - it's hard to get 
anything done with an unresponsive app of the screen. I'll try to dig out more 
info the next time I get a lockup.

The one thing that does seem completely consistent is that the lockup happens 
after several minutes of being idle (i.e. no keyboard or mouse input).

     AndyM