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

Previous Next

Packages: w32, emacs;

Reported by: Andy Moreton <andrewjmoreton <at> gmail.com>

Date: Thu, 8 Nov 2012 12:58:02 UTC

Severity: normal

Found in version 24.3.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log

View this message in rfc822 format

From: "Fabrice Niessen" <fni <at> missioncriticalit.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12832 <at> debbugs.gnu.org, Andy Moreton <andrewjmoreton <at> gmail.com>
Subject: bug#12832: 24.3.50; Emacs lockup when idle
Date: Tue, 13 Nov 2012 14:13:19 +0100

Dear Eli,

Eli Zaretskii wrote:
> It looks like Fabrice just saw a very similar, if not identical,
> lockup:
>
>> Thread 8 (Thread 6696.0x20fc):
>> #0  0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #1  0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #2  0x00000005 in ?? ()
>> #3  0x00000004 in ?? ()
>> #4  0x00000001 in ?? ()
>> #5  0x5adcffd0 in ?? ()
>> #6  0x00000000 in ?? ()
>>
>> Lisp Backtrace:
>> "redisplay_internal (C function)" (0x167d33c)
>>
>> Thread 7 (Thread 6696.0x4b8):
>> #0  0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #1  0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #2  0x7199402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
>> #3  0x719957c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
>> #4  0x719f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll
>> #5  0x0108d925 in _sys_read_ahead (fd=4) at w32.c:6079
>> #6  0x01033127 in reader_thread (arg=0x167dc98) at w32proc.c:838
>> #7  0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
>> #8  0x00000000 in ?? ()
>>
>> Lisp Backtrace:
>> "redisplay_internal (C function)" (0x167d33c)
>>
>> Thread 6 (Thread 6696.0x1114):
>> #0  0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #1  0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #2  0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll
>> #3  0x000005fc in ?? ()
>> #4  0x00000000 in ?? ()
>>
>> Lisp Backtrace:
>> "redisplay_internal (C function)" (0x167d33c)
>>
>> Thread 5 (Thread 6696.0x2344):
>> #0  0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #1  0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #2  0x7199402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
>> #3  0x719957c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
>> #4  0x719f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll
>> #5  0x0108d925 in _sys_read_ahead (fd=5) at w32.c:6079
>> #6  0x01033127 in reader_thread (arg=0x167dc40) at w32proc.c:838
>> #7  0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
>> #8  0x00000000 in ?? ()
>>
>> Lisp Backtrace:
>> "redisplay_internal (C function)" (0x167d33c)
>>
>> Thread 4 (Thread 6696.0x15e4):
>> #0  0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #1  0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #2  0x7c8025db in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll
>> #3  0x0000060c in ?? ()
>> #4  0x00000000 in ?? ()
>>
>> Lisp Backtrace:
>> "redisplay_internal (C function)" (0x167d33c)
>>
>> Thread 3 (Thread 6696.0xc28):
>> #0  0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #1  0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #2  0x7c929b23 in ntdll!RtlpWaitForCriticalSection () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #3  0x7c911046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #4  0x006811a0 in ?? ()
>> #5  0x012e871e in post_msg (lpmsg=0x5b8cfa94) at w32xfns.c:279
>> #6 0x01147b48 in my_post_msg (wmsg=0x5b8cfa94, hwnd=0x2cec0092, msg=0,
>> wParam=103, lParam=2228225) at w32fns.c:1942
>> #7 0x01148c58 in post_character_message (hwnd=0x2cec0092, msg=0, wParam=103,
>> lParam=2228225, modifiers=67108864) at w32fns.c:2686
>> #8  0x01149a12 in w32_wnd_proc (hwnd=0x2cec0092, msg=258, wParam=103, lParam=2228225) at w32fns.c:3064
>> #9  0x7e398734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/USER32.dll
>> #10 0x2cec0092 in ?? ()
>> #11 0x00000102 in ?? ()
>> #12 0x00000067 in ?? ()
>> #13 0x00220001 in ?? ()
>> #14 0x01148c5a in post_character_message (hwnd=0x0, msg=1535966776,
>> wParam=18123866, lParam=1535966820, modifiers=2117699606)
>>     at w32fns.c:2687
>> #15 0xdcbaabcd in ?? ()
>> #16 0x00000000 in ?? ()
>>
>> Lisp Backtrace:
>> "redisplay_internal (C function)" (0x167d33c)
>>
>> Thread 2 (Thread 6696.0x1788):
>> #0  0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #1  0x7c91d21a in ntdll!ZwDelayExecution () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #2  0x7c8023f1 in SleepEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll
>> #3  0x00000000 in ?? ()
>>
>> Lisp Backtrace:
>> "redisplay_internal (C function)" (0x167d33c)
>>
>> Thread 1 (Thread 6696.0x4d0):
>> #0  0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #1  0x7e3eceba in USER32!SetInternalWindowPos () from /cygdrive/c/WINDOWS/system32/USER32.dll
>> #2  0x7e3cf408 in USER32!SetMenu () from /cygdrive/c/WINDOWS/system32/USER32.dll
>> #3 0x012c6395 in set_frame_menubar (f=0x3926840
>> <__register_frame_info+59926592>, first_time=false, deep_p=false) at
>> w32menu.c:610
>> #4 0x01200075 in update_menu_bar (f=0x3926840
>> <__register_frame_info+59926592>, save_match_data=0, hooks_run=1) at
>> xdisp.c:11327
>> #5  0x011ffa95 in prepare_menu_bars () at xdisp.c:11205
>> #6  0x012055fa in redisplay_internal () at xdisp.c:13081
>> #7  0x012034a1 in redisplay () at xdisp.c:12653
>> #8 0x0103b2a2 in read_char (commandflag=1, nmaps=3, maps=0x82f9b0,
>> prev_event=57358362, used_mouse_menu=0x82fa83, end_time=0x0)
>>     at keyboard.c:2428
>> #9  0x0104eef4 in read_key_sequence (keybuf=0x82fc00, bufsize=30, prompt=57358362, dont_downcase_last=false,
>>     can_return_switch_frame=true, fix_current_buffer=true) at keyboard.c:9230
>> #10 0x010385c4 in command_loop_1 () at keyboard.c:1458
>> #11 0x01010e86 in internal_condition_case (bfun=0x10380de <command_loop_1>,
>> handlers=57408946, hfun=0x10378fd <cmd_error>)
>>     at eval.c:1288
>> #12 0x01037d57 in command_loop_2 (ignore=57358362) at keyboard.c:1167
>> #13 0x010108e3 in internal_catch (tag=57398802, func=0x1037d33 <command_loop_2>, arg=57358362) at eval.c:1059
>> #14 0x01037d11 in command_loop () at keyboard.c:1146
>> #15 0x010372cb in recursive_edit_1 () at keyboard.c:778
>> #16 0x010375f8 in Frecursive_edit () at keyboard.c:842
>> #17 0x01002920 in main (argc=1, argv=0xa44480) at emacs.c:1552
>>
>> Lisp Backtrace:
>> "redisplay_internal (C function)" (0x167d33c)
>> (gdb)
>> (gdb) xbacktrace
>> "redisplay_internal (C function)" (0x167d33c)
>
> This backtrace is more informative.  I'm beginning to think that
> there's some deadlock between threads that use a critical section,
> because all of the threads are parked at the same interface:
> ntdll!LdrAccessResource, and at least one of them waits for a critical
> section:
>
>> Thread 3 (Thread 6696.0xc28):
>> #0  0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #1  0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #2  0x7c929b23 in ntdll!RtlpWaitForCriticalSection () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #3  0x7c911046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> #4  0x006811a0 in ?? ()
>> #5  0x012e871e in post_msg (lpmsg=0x5b8cfa94) at w32xfns.c:279
>> #6 0x01147b48 in my_post_msg (wmsg=0x5b8cfa94, hwnd=0x2cec0092, msg=0,
>> wParam=103, lParam=2228225) at w32fns.c:1942
>
> Fabrice, what bzr revision did you compile

I did not compile it myself. I took a version compiled (on 22 October) by Dani
Moncayo, downloaded from https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8.

However, eval'ing emacs-bzr-version returns:

"110618 monnier <at> iro.umontreal.ca-20121022132928-232zm0fecassmhfb"

> and with what version of GCC?

No idea, sorry...

Does his recipe
(https://www.dropbox.com/sh/7jr3vbv9tm1zod0/qpjXONObVR/emacs-build-recipe.txt)
give you valuable information?

Best regards,
Fabrice
This bug report was last modified 12 years and 275 days ago.

Previous Next

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