Subject: bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes

From: "Fabrice Niessen" <[email-masked]>
Date: Wed, 14 Nov 2012 10:29:53 +0100

Hi Eli,

Eli Zaretskii wrote:
>> From: "Fabrice Niessen" <[email-masked]>
>> 
>> 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