bug#16234: 24.3.50; emacs_backtrace.txt

bug#16234: 24.3.50; emacs_backtrace.txt

[Drew Adams]

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@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'

bug#16234: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

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

bug#16234: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 24 Dec 2013 05:39:37 +0100
> Cc: 16234@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.

bug#16234: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

On Tue, Dec 24, 2013 at 6:56 PM, Eli Zaretskii <eliz@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.

bug#16234: 24.3.50; emacs_backtrace.txt

[Drew Adams]

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