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

Previous Next

Full log

View this message in rfc822 format

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12832 <at> debbugs.gnu.org
Subject: bug#12832: 24.3.50; Emacs lockup when idle
Date: Thu, 08 Nov 2012 18:33:11 +0000

On 08/11/2012 16:28, Eli Zaretskii wrote:
>> Date: Thu, 08 Nov 2012 12:57:18 +0000
>> From: Andy Moreton <andrewjmoreton <at> gmail.com>
>>
>> Windows Emacs (built from r110828) was idle for a few minutes while I made a
>> coffee. On returning, emacs was completely unresponsive and redisplay
>> was not drawing anything.
>
> If this recurs, maybe try bisecting to find the problematic commit.
> Do you know what was the previous revision which you used?

I rebuild emacs every day from trunk, but only do a full bootstrap when 
necessary. I have updated the Mingw compiler this week though, so that could 
be an issue. I'll try bisecting (and downgrading the compiler) if I see this 
again.

> Also, how was Emacs unresponsive -- did it consume any CPU cycles at
> all?  Were all the threads locked up, or just some?  If you detach
> from it, then attach again, do you see exactly the same backtrace?

Emacs was not consuming any cycles - the system was completely idle.

>> Thread 1 (Thread 8744.0xf50):
>> #0  0x7c90e514 in ntdll!LdrAccessResource () from C:\WINDOWS\system32\ntdll.dll
>> No symbol table info available.
>> #1  0x7c90d2aa in ntdll!ZwDuplicateObject () from C:\WINDOWS\system32\ntdll.dll
>> No symbol table info available.
>> #2  0x7c80df03 in KERNEL32!DuplicateHandle () from
>> C:\WINDOWS\system32\kernel32.dll
>> No symbol table info available.
>> #3  0xffffffff in ?? ()
>> No symbol table info available.
>> #4  0xfffffffe in ?? ()
>> No symbol table info available.
>> #5  0xffffffff in ?? ()
>> No symbol table info available.
>> #6  0x0162acb8 in real_itimer ()
>> No symbol table info available.
>> #7  0x00000000 in ?? ()
>> No symbol table info available.
>
> This is the main thread, but its backtrace looks like the stack is
> smashed, and real_itimer is a variable, not a function.
>
> We need more data points on this.

I'll see if this is reproduceable and try to get more info.

    AndyM

Previous Next

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