|
From: | Andy Moreton |
Subject: | bug#12832: 24.3.50; Emacs lockup when idle |
Date: | Tue, 13 Nov 2012 16:00:30 +0000 |
User-agent: | Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |