GNU bug report logs - #16801
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 16801 in the body.
You can then email your comments to 16801 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: Tue, 18 Feb 2014 13:49:50 -0800 (PST)

Exception 0xc0000005 at this address:
010e6b0a

Backtrace:
011fbd99
011fbe0a
010f043b
011149c4
0111499f
011149f8
010011e6
75f2fff7
77d674fb
77d29f41




In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2014-02-11 on ODIEONE
Bzr revision: 116410 lekktu <at> gmail.com-20140211204823-l9l2s6tktfitq266
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 16801 <at> debbugs.gnu.org
Subject: Re: bug#16801: 24.3.50; emacs_backtrace.txt
Date: Tue, 18 Feb 2014 22:56:31 +0100

??
??:0
w32_backtrace at w32fns.c:8431
emacs_abort at w32fns.c:8463
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 16801 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 16801 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#16801: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Feb 2014 05:41:53 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 18 Feb 2014 22:56:31 +0100
> Cc: 16801 <at> debbugs.gnu.org
> 
> ??
> ??:0
> w32_backtrace at w32fns.c:8431
> emacs_abort at w32fns.c:8463
> 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

What about that 1st address:

> Exception 0xc0000005 at this address:
> 010e6b0a

?  That's the important piece of info.

Thanks.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16801 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#16801: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Feb 2014 13:56:02 +0100

On Wed, Feb 19, 2014 at 4:41 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> What about that 1st address:

Sorry, my bad.

This is the full output:

??
??:0
cache_face at xfaces.c:4377
??
??:0
??
??:0
w32_backtrace at w32fns.c:8431
emacs_abort at w32fns.c:8463
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 #19 received at 16801-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 16801-done <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#16801: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Feb 2014 18:48:09 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Wed, 19 Feb 2014 13:56:02 +0100
> Cc: Drew Adams <drew.adams <at> oracle.com>, 16801 <at> debbugs.gnu.org
> 
> On Wed, Feb 19, 2014 at 4:41 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > What about that 1st address:
> 
> Sorry, my bad.

Nothing to be sorry about, and thanks for doing this.

> This is the full output:
> 
> ??
> ??:0
> cache_face at xfaces.c:4377

This is here:

  #ifdef GLYPH_DEBUG
    /* Check that FACE got a unique id.  */
    {
      int j, n;
      struct face *face1;

      for (j = n = 0; j < FACE_CACHE_BUCKETS_SIZE; ++j)
	for (face1 = c->buckets[j]; face1; face1 = face1->next)
	  if (face1->id == i)  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
	    ++n;

      eassert (n == 1);
    }
  #endif /* GLYPH_DEBUG */

So I guess 'face1' is an invalid (but non-NULL) pointer.  I have no
idea how this could happen (anyone?), but since this is a debugging
code, I don't thinks it's too important to figure that out.

Closing.

Previous Next

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