[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes
From: |
Fabrice Niessen |
Subject: |
bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes |
Date: |
Tue, 09 Oct 2012 21:46:28 +0200 |
User-agent: |
Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (windows-nt) |
Eli,
Eli Zaretskii wrote:
>> 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.
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@missioncriticalit.com
☎ +32 2-757.10.15
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, (continued)
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Drew Adams, 2012/10/21
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Eli Zaretskii, 2012/10/21
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Drew Adams, 2012/10/21
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Eli Zaretskii, 2012/10/21
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Drew Adams, 2012/10/21
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Fabrice Niessen, 2012/10/21
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Eli Zaretskii, 2012/10/21
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Eli Zaretskii, 2012/10/09
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Drew Adams, 2012/10/09
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Eli Zaretskii, 2012/10/09
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes,
Fabrice Niessen <=
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Eli Zaretskii, 2012/10/09
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Fabrice Niessen, 2012/10/09
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Eli Zaretskii, 2012/10/09
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Fabrice Niessen, 2012/10/10
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Fabrice Niessen, 2012/10/10
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Fabrice Niessen, 2012/10/10
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Stefan Monnier, 2012/10/10
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Fabrice Niessen, 2012/10/10
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Eli Zaretskii, 2012/10/10
- bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes, Fabrice Niessen, 2012/10/10