GNU bug report logs - #12832
24.3.50; Emacs lockup when idle

Previous Next

Full log

Message #53 received at 12832 <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12832 <at> debbugs.gnu.org, fni <at> missioncriticalit.com, dmoncayo <at> gmail.com
Subject: Re: bug#12832: 24.3.50; Emacs lockup when idle
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 <andrewjmoreton <at> gmail.com>
>> CC: Dani Moncayo <dmoncayo <at> gmail.com>, fni <at> missioncriticalit.com,
>>  12832 <at> debbugs.gnu.org
>>
>> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.