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

[Eli Zaretskii <eliz@gnu.org>]

> From: "Fabrice Niessen" <fni@missioncriticalit.com>
> Cc: Drew Adams <drew.adams@oracle.com>,  lekktu@gmail.com,  12579@debbugs.gnu.org
> Date: Tue, 09 Oct 2012 08:36:54 +0200
> 
> Here some food... I hope/guess it will help a lot to pinpoint what's going
> wrong.

Thanks.  We are not there yet.

> Note that I have the _impression_ that the problem lies, somehow, in packages
> I would load from my .emacs file (such as idle-require, auto-complete, helm,
> etc.). *NOT* that _they_ are wrong, but, when loaded, the problem would be
> (more) apparent.

helm is definitely involved, see below.  Not sure it's the culprit,
though.

> #1  0x011548c0 in emacs_abort () at w32fns.c:7214
> #2  0x01055503 in sys_kill (pid=5624, sig=22) at w32proc.c:1432
> #3  0x010014fc in fatal_error_backtrace (sig=22, backtrace_limit=2147483647) at emacs.c:331
> #4  0x010431b7 in die (msg=0x1537030 "assertion failed: buffer->base_buffer->indirections > 0", file=0x1535810 "buffer.c",
>     line=1664) at alloc.c:6398
> #5  0x010ac068 in compact_buffer (buffer=0x3c44600) at buffer.c:1664
> #6  0x0103fde2 in Fgarbage_collect () at alloc.c:5085

This one we already saw.  I think it's already fixed in the
development sources, so either try the next development snapshot or
wait for the pretest of v24.3.

> #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  0x00000008 in ?? ()
> #8  0x00000004 in ?? ()
> #9  0x04ae9e70 in ?? ()
> #10 0x0105fdc8 in sys_close (fd=4) at w32.c:5960
> #11 0x01145749 in emacs_close (fd=4) at sysdep.c:1851
> #12 0x0104b550 in deactivate_process (proc=78552693) at process.c:3929
> #13 0x0104457e in remove_process (proc=78552693) at process.c:746
> #14 0x010519b6 in status_notify (deleting_process=0x4ae9e70) at process.c:6673
> [...]
> Lisp Backtrace:
> "delete-process" (0x82a55c)
> "helm-kill-async-process" (0x82a74c)
> "mapc" (0x82a83c)
> "helm-kill-async-processes" (0x82a980)
> "helm-update" (0x82ab80)
> "if" (0x82adf4)
> "helm-check-new-input" (0x82aee0)
> [...]
> "funcall" (0x82ee50)
> "unwind-protect" (0x82f024)
> "helm-let-internal" (0x82f110)
> "if" (0x82f364)
> "helm" (0x82f450)
> "helm-other-buffer" (0x82f660)
> "helm-for-files" (0x82f944)
> "call-interactively" (0x82fb54)

This backtrace (and all the rest like it which you got by attaching to
an Emacs that appears "hung") is not helpful.  All they say is that
helm, for whatever reason, tried to kill all asynchronous subprocesses
(any idea why would it want to do that?) as part of running the
command 'helm-for-files', and that this attempt to kill the processes
hung for some reason.  But it doesn't show where Emacs is hung or
inflooping, because attaching to such a process catches it in some
random place.  What is needed is information about where Emacs loops.
I guess it's time for another GDB lesson, this time copied from
etc/DEBUG:

  If Emacs is in an infinite loop, try to determine where the loop
  starts and ends.  The easiest way to do this is to use the GDB command
  `finish'.  Each time you use it, Emacs resumes execution until it
  exits one stack frame.  Keep typing `finish' until it doesn't
  return--that means the infinite loop is in the stack frame which you
  just tried to finish.

Can you please do this, after attaching to Emacs, and report which
'finish' command doesn't return?