GNU bug report logs - #16234
24.3.50; emacs_backtrace.txt

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16234 in the body.
You can then email your comments to 16234 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; emacs_backtrace.txt
Date: Mon, 23 Dec 2013 20:23:41 -0800 (PST)

Hop this helps somehow.  This was with my setup, when I hit
`M-k' in the minibuffer.  (It is bound to a command the empties
the minibuffer.  And it was not the first time I had hit it
during the same command invocation where the crash occurred.)

Exception 0xc0000005 at this address:
011d7756

Backtrace:
011fac31
011faca2
010ef7b2
01113d88
01113d63
01113dbc
010011e6
7501fff7
774074fb
773c9f41




In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-12-22 on ODIEONE
Bzr revision: 115700 xfq.free <at> gmail.com-20131222231942-q8ftfeg3ft2a1t83
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' CPPFLAGS=-Ic:/Devel/emacs/include
 LDFLAGS=-Lc:/Devel/emacs/lib'

Message #8 received at 16234 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 16234 <at> debbugs.gnu.org
Subject: Re: bug#16234: 24.3.50; emacs_backtrace.txt
Date: Tue, 24 Dec 2013 05:39:37 +0100

??
??:0
find_interval at intervals.c:679
??
??:0
??
??:0
w32_backtrace at w32fns.c:8385
emacs_abort at w32fns.c:8417
terminate_due_to_signal at emacs.c:378
handle_fatal_signal at sysdep.c:1628
deliver_thread_signal at sysdep.c:1602
deliver_fatal_thread_signal at sysdep.c:1640
?? at crt1.c:0
??
??:0
??
??:0
??
??:0

Message #11 received at 16234 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: drew.adams <at> oracle.com, 16234 <at> debbugs.gnu.org
Subject: Re: bug#16234: 24.3.50; emacs_backtrace.txt
Date: Tue, 24 Dec 2013 19:56:29 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 24 Dec 2013 05:39:37 +0100
> Cc: 16234 <at> debbugs.gnu.org
> 
> ??
> ??:0
> find_interval at intervals.c:679
> ??
> ??:0
> ??
> ??:0
> w32_backtrace at w32fns.c:8385
> emacs_abort at w32fns.c:8417
> terminate_due_to_signal at emacs.c:378
> handle_fatal_signal at sysdep.c:1628
> deliver_thread_signal at sysdep.c:1602
> deliver_fatal_thread_signal at sysdep.c:1640

Aha! the trap worked!  I installed in trunk revision something that
will hopefully show us a full backtrace from intervals.c:679, so we
could try to find out whodunit.

Thanks.

Message #14 received at 16234 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Drew Adams <drew.adams <at> oracle.com>, 16234 <at> debbugs.gnu.org
Subject: Re: bug#16234: 24.3.50; emacs_backtrace.txt
Date: Wed, 25 Dec 2013 05:17:18 +0100

On Tue, Dec 24, 2013 at 6:56 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Aha! the trap worked!  I installed in trunk revision something that
> will hopefully show us a full backtrace from intervals.c:679, so we
> could try to find out whodunit.

emacs-20131225-r115738-bin-i386.zip is on its way to Dropbox.

Message #17 received at 16234 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juanma Barranquero <lekktu <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 16234 <at> debbugs.gnu.org
Subject: RE: bug#16234: 24.3.50; emacs_backtrace.txt
Date: Tue, 24 Dec 2013 21:29:22 -0800 (PST)

> > Aha! the trap worked!  I installed in trunk revision something that
> > will hopefully show us a full backtrace from intervals.c:679, so we
> > could try to find out whodunit.
> 
> emacs-20131225-r115738-bin-i386.zip is on its way to Dropbox.

Thanks.  I picked it up and tried it.  But as I said earlier, I'm
afraid the crash was fortuitous, not something I can easily reproduce.
As I mentioned, I had already used M-k in the minibuffer more than
once, even for the same command invocation.  Only once did the crash
occur when I did that.

So far, I have not gotten a crash.  Will of course let you know.


[However, something else (horrible) must have changed in this build,
because now when I use my (own) command to open a file, it takes
multiple seconds just to calculate the list of candidate files in my
usual directory.  Nothing to do with the problem at hand.  But it
does mean that this build is not something I can use, to do more
than test for this bug and hope for another crash.]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.