bug#12832: 24.3.50; Emacs lockup when idle

[Andy Moreton]

On 13/11/2012 15:16, Eli Zaretskii wrote:
> > Date: Tue, 13 Nov 2012 14:25:30 +0000
> > From: Andy Moreton <andrewjmoreton@gmail.com>
> > CC: Dani Moncayo <dmoncayo@gmail.com>, fni@missioncriticalit.com,
> >  12832@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