Package: emacs;
Reported by: "Fabrice Niessen" <fni <at> missioncriticalit.com>
Date: Fri, 5 Oct 2012 15:52:01 UTC
Severity: normal
Found in version 24.1
Done: npostavs <at> users.sourceforge.net
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: "Fabrice Niessen" <fni <at> missioncriticalit.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 12579 <at> debbugs.gnu.org, lekktu <at> gmail.com, thierry.volpiatto <at> gmail.com Subject: bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes Date: Wed, 14 Nov 2012 10:29:53 +0100
Hi Eli,
Eli Zaretskii wrote:
>> From: "Fabrice Niessen" <fni <at> missioncriticalit.com>
>>
>> Got it! Same Emacs version, same shell config (bash), using only helm-locate.
>>
>> There is an es.exe process which is "suspended", whatever it means. Not shown
>> under Emacs, but maybe because it's suspended?
>
> Its parent process, Bash, is not shown, so this process is an orphan.
Got a new Emacs freeze. More info here! Read on...
Freeze just occurred:
http://content.screencast.com/users/fniessen/folders/Jing/media/8b0f5dfa-470d-4d49-a7fb-a86b8b1d9e04/2012-11-14_0932.png
One es.exe process hangin' around.
Classical GDB trace:
--8<---------------cut here---------------start------------->8---
$ gdb -p 9512
GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
[...]
Attaching to process 9512
[New Thread 9512.0x193c]
[New Thread 9512.0x1750]
[New Thread 9512.0x1c90]
[New Thread 9512.0x2714]
[New Thread 9512.0x1594]
[New Thread 9512.0x2110]
[New Thread 9512.0x1010]
[New Thread 9512.0x17c0]
[New Thread 9512.0x1998]
[New Thread 9512.0x1eec]
[...]
Thread 1 (Thread 9512.0x193c):
#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 0x00a41fbc in ?? ()
#5 0x77bfd114 in msvcrt!_close () from /cygdrive/c/WINDOWS/system32/msvcrt.dll
#6 0x00000004 in ?? ()
#7 0x0000000b in ?? ()
#8 0x00000004 in ?? ()
#9 0x037fb6f0 in __register_frame_info ()
#10 0x0108d41e in sys_close (fd=4) at w32.c:5918
#11 0x011452a8 in emacs_close (fd=4) at sysdep.c:2082
#12 0x01029ce4 in deactivate_process (proc=58701557) at process.c:3924
#13 0x01022d92 in remove_process (proc=58701557) at process.c:735
#14 0x0102ffff in status_notify (deleting_process=0x37fb6f0 <__register_frame_info+58701552>) at process.c:6606
#15 0x01023263 in Fdelete_process (process=58701557) at process.c:850
#16 0x01013174 in eval_sub (form=65502598) at eval.c:2139
[...]
#194 0x01002920 in main (argc=1, argv=0xa44480) at emacs.c:1552
Lisp Backtrace:
"delete-process" (0x829a2c)
"helm-kill-async-process" (0x829b70)
"while" (0x829e04)
"helm-kill-async-processes" (0x829ef0)
"helm-update" (0x82a0f0)
"if" (0x82a364)
"helm-check-new-input" (0x82a450)
"progn" (0x82a6a4)
"unwind-protect" (0x82a7d4)
"save-current-buffer" (0x82a934)
"let" (0x82ab04)
"progn" (0x82ac34)
"condition-case" (0x82ae14)
"let" (0x82afe4)
"helm-check-minibuffer-input-1" (0x82b27c)
"apply" (0x82b278)
"byte-code" (0x82b4ec)
"timer-event-handler" (0x82b96c)
"read-from-minibuffer" (0x82c46c)
"let" (0x82c694)
"cond" (0x82c7f4)
"let*" (0x82c984)
"save-current-buffer" (0x82cae4)
"helm-read-pattern-maybe" (0x82cbd0)
"unwind-protect" (0x82ce34)
"progn" (0x82cf64)
"unwind-protect" (0x82d094)
"let" (0x82d264)
"let" (0x82d434)
"condition-case" (0x82d614)
"unwind-protect" (0x82d744)
"let" (0x82d914)
"catch" (0x82db04)
"helm-internal" (0x82dc94)
"apply" (0x82dd40)
"if" (0x82df44)
"if" (0x82e0a4)
"let" (0x82e274)
"helm" (0x82e404)
"apply" (0x82e4b0)
0x3e44988 Lisp type 6
"funcall" (0x82e6f0)
"unwind-protect" (0x82e8c4)
"helm-let-internal" (0x82e9b0)
"if" (0x82ec04)
"if" (0x82ed64)
"let" (0x82ef34)
"helm" (0x82f020)
"let" (0x82f334)
"helm-locate-with-db" (0x82f420)
"helm-locate-1" (0x82f630)
"helm-locate" (0x82f934)
"call-interactively" (0x82fb64)
(gdb) thread 1
[Switching to thread 1 (Thread 9512.0x193c)]
#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) frame 14
#14 0x0102ffff in status_notify (deleting_process=0x37fb6f0 <__register_frame_info+58701552>) at process.c:6606
6606 process.c: No such file or directory.
(gdb) print *p
$1 = {
header = {
size = 1073872914,
next = {
nbytes = 144,
buffer = 0x90,
vector = 0x90
}
},
tty_name = 57358362,
name = 58410881,
command = 84995798,
filter = 57358386,
sentinel = 62531782,
log = 57358362,
buffer = 61534213,
childp = 57358386,
plist = 57358362,
type = 57481914,
mark = 79175683,
status = 85116598,
decode_coding_system = 59149866,
decoding_buf = 20036945,
encode_coding_system = 59149842,
encoding_buf = 20036945,
write_queue = 57358362,
gnutls_cred_type = 57358362,
pid = 6672,
infd = 4,
outfd = 11,
tick = 22,
update_tick = 22,
decoding_carryover = 0,
read_output_delay = 0,
adaptive_read_buffering = 1,
read_output_skip = 0,
kill_without_query = 0,
pty_flag = 0,
inherit_coding_system_flag = 0,
raw_status_new = 0,
raw_status = 0,
gnutls_initstage = GNUTLS_STAGE_EMPTY,
gnutls_state = 0x0,
gnutls_x509_cred = 0x0,
gnutls_anon_cred = 0x0,
gnutls_log_level = 0,
gnutls_handshakes_tried = 0,
gnutls_p = 0
}
(gdb) print p->name
$2 = 58410881
(gdb) xstring
$3 = (struct Lisp_String *) 0x37b4780 <__register_frame_info+58410880>
"locate-process"
(gdb) print p->command
$4 = 84995798
(gdb) xtype
Lisp_Cons
(gdb) xcons
$5 = (struct Lisp_Cons *) 0x510eed0
{
car = 0x3748091,
u = {
cdr = 0x510eede,
chain = 0x510eede
}
}
(gdb) quit
A debugging session is active.
Inferior 1 [process 9512] will be detached.
Quit anyway? (y or n) y
Detaching from program: /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe, Pid 9512
--8<---------------cut here---------------end--------------->8---
Though, I've no process with PID 6672, as you can see on the above screenshot.
As you say, it could be the PID of Bash that already exited.
> Can you kill it from Process Explorer (by pressing Del)? If you can,
> does Emacs get out of the lockup?
Now, killing es.exe from the Process Explorer *did unblock Emacs*, as you can
see on
http://content.screencast.com/users/fniessen/folders/Jing/media/fd8b4e53-5232-451a-9757-7623950365cd/2012-11-14_0938.png:
I just recovered where I was, in Helm, with the correct files show now -- I
had previously typed more characters in the pattern, when Emacs just froze...
Now, they reappeared, with correct results from the "locate" command.
Great news, I guess, in the understanding of what happens...
> Next thing to try is to run es.exe from cmdproxy, not from the Cygwin
> Bash.
Next thing for me, then, is to try without Bash for shell-file-name:
--8<---------------cut here---------------start------------->8---
(setq shell-file-name "cmdproxy")
(setq explicit-shell-file-name "bash")
--8<---------------cut here---------------end--------------->8---
Best regards,
Fabrice
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.