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

["Fabrice Niessen" <fni-djc/iPCCuDYQheJpep6IedvLeJWuRmrY@public.gmane.org>]

Eli,

Eli Zaretskii wrote:
>> From: "Fabrice Niessen" <fni-djc/iPCCuDYQheJpep6IedvLeJWuRmrY@public.gmane.org>
>> Cc: Drew Adams <drew.adams-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,  lekktu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,  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.

Thanks for your precious help, anyway.

>> 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.

OK.

>> #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.

There is no new development snapshot on
http://alpha.gnu.org/gnu/emacs/windows/.

The same applies for a pretest version: nothing new since August on
http://alpha.gnu.org/gnu/emacs/pretest/windows/.

Still a bit of patience?

>> #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.

Sometimes (once a day, I'd say), I get errors from (Cygwin's) Bash, when
Helm-for-files is running: I get a popup, click OK, and then Helm goes on.

Maybe the crashes happen when I don't get such a popup, but some process is
still crashed, letting Emacs with no response?

> 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?

For sure, I'll do. Wait. Except that I don't have a .gdbinit file for Emacs
24.1, and that I've the impression that only Emacs 24.1 does hang from time to
time.

Should I take a snapshot from Emacs 24.1 on
http://alpha.gnu.org/gnu/emacs/windows/?  If yes, which one can I take: there
is no version indicated there... How can I know which file is a snapshot of
24.1?

Another question: before typing finish, do I do the other sequence as well:

- (continue),
- thread apply all backtrace, and
- xbacktrace?

Thanks for doing me learn along this painful process!

Best regards,
Fabrice

-- 
Fabrice Niessen
Pre-sales, Network and Software Engineer
M i s s i o n   C r i t i c a l   I T
✉ fni-djc/iPCCuDYQheJpep6IedvLeJWuRmrY@public.gmane.org
☎ +32 2-757.10.15