From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes Date: Tue, 09 Oct 2012 19:17:26 +0200 Message-ID: <83wqyzzhsp.fsf@gnu.org> References: <80vcep2v3z.fsf@somewhere.org> <83txu87vlp.fsf@gnu.org> <80391srlog.fsf@somewhere.org> <83lifj7tlg.fsf@gnu.org> <80obkfrdrk.fsf@somewhere.org> <83haq77oar.fsf@gnu.org> <9406B35D2F4F4A12B64463151C5EC515@us.oracle.com> <837gr25dsn.fsf@gnu.org> <80ipakjgmx.fsf@somewhere.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1349803126 30723 80.91.229.3 (9 Oct 2012 17:18:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Oct 2012 17:18:46 +0000 (UTC) Cc: lekktu@gmail.com, 12579@debbugs.gnu.org To: Fabrice Niessen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 09 19:18:52 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TLdSD-0001pm-WA for geb-bug-gnu-emacs@m.gmane.org; Tue, 09 Oct 2012 19:18:50 +0200 Original-Received: from localhost ([::1]:41783 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLdS7-0007sG-MY for geb-bug-gnu-emacs@m.gmane.org; Tue, 09 Oct 2012 13:18:43 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLdS3-0007gn-4A for bug-gnu-emacs@gnu.org; Tue, 09 Oct 2012 13:18:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLdRt-00049e-2l for bug-gnu-emacs@gnu.org; Tue, 09 Oct 2012 13:18:39 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53959) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLdRs-00049V-VG for bug-gnu-emacs@gnu.org; Tue, 09 Oct 2012 13:18:28 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TLdSQ-0000wH-FJ for bug-gnu-emacs@gnu.org; Tue, 09 Oct 2012 13:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Oct 2012 17:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12579 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: Original-Received: via spool by 12579-submit@debbugs.gnu.org id=B12579.13498031093561 (code B ref 12579); Tue, 09 Oct 2012 17:19:02 +0000 Original-Received: (at 12579) by debbugs.gnu.org; 9 Oct 2012 17:18:29 +0000 Original-Received: from localhost ([127.0.0.1]:35977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TLdRp-0000vK-Fk for submit@debbugs.gnu.org; Tue, 09 Oct 2012 13:18:28 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:64056) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TLdRi-0000v0-KV for 12579@debbugs.gnu.org; Tue, 09 Oct 2012 13:18:23 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MBM00E00YM3UW00@a-mtaout22.012.net.il> for 12579@debbugs.gnu.org; Tue, 09 Oct 2012 19:17:24 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MBM00DZ2YP0TRG0@a-mtaout22.012.net.il>; Tue, 09 Oct 2012 19:17:24 +0200 (IST) In-reply-to: <80ipakjgmx.fsf@somewhere.org> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:65427 Archived-At: > From: "Fabrice Niessen" > Cc: Drew Adams , 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?