GNU bug report logs - #18438
24.4.50; assertion failed in bidi.c

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: aidalgol <at> amuri.net
Cc: 18438 <at> debbugs.gnu.org, kbrown <at> cornell.edu
Subject: bug#18438: 24.4.50; assertion failed in bidi.c
Date: Mon, 20 Oct 2014 18:46:13 +0300

> Date: Mon, 20 Oct 2014 09:20:52 +1300
> From: aidalgol <at> amuri.net
> Cc: Ken Brown <kbrown <at> cornell.edu>, <18438 <at> debbugs.gnu.org>
> 
> Not sure whether this is relevant, but I have been getting a recurring 
> seg. fault in w32xfns.c, but in a different function, and in lisp.h.  
> (Why is there code complex enough in a header file to warrant asserts 
> there?)

The assertions are in inline functions that manipulate Lisp objects.
In a binary configured with --enable-checking, each Lisp object is
tested for validity when the C code extracts from it a C pointer to
the corresponding structure.

> #0  0x000000010051ce24 in CHAR_TABLE_REF_ASCII (ct=25778897525, idx=112) at lisp.h:1492
>         tbl = 0x0
>         val = 2230448
> #1  0x000000010051cefa in CHAR_TABLE_REF (ct=25778897525, idx=112) at lisp.h:1510
> No locals.
> #2  0x0000000100520ea9 in syntax_property_entry (c=112, via_property=true) at syntax.h:96
> No locals.

This is again a non-sensical backtrace.  The code near line 1492 of
lisp.h, where it crashes is this (line 1492 is the last one):

  INLINE Lisp_Object
  CHAR_TABLE_REF_ASCII (Lisp_Object ct, ptrdiff_t idx)
  {
    struct Lisp_Char_Table *tbl = NULL;
    Lisp_Object val;
    do
      {
	tbl = tbl ? XCHAR_TABLE (tbl->parent) : XCHAR_TABLE (ct); <<<<<<<<<

So, if 'tbl' is a NULL pointer, it cannot be dereferenced, right?  And
yet the local variables clearly show that 'tbl' _is_ NULL, and it
still is dereferenced (and causes the segfault)!

> #0  0x000000010051ceb4 in CHAR_TABLE_REF_ASCII (ct=25787135005, idx=44) at lisp.h:1492
>         tbl = 0x0
>         val = 2230320
> #1  0x000000010051cf8a in CHAR_TABLE_REF (ct=25787135005, idx=44) at lisp.h:1510
> No locals.

Same here.

> #0  0x0000000100680609 in deselect_palette (f=0x0, hdc=0x0) at w32xfns.c:123
> No locals.
> #1  0x00000001006806d8 in release_frame_dc (f=0x0, hdc=0x0) at w32xfns.c:154
>         ret = 0
> #2  0x0000000100683d36 in uniscribe_encode_char (font=0x600764000, c=32) at w32uniscribe.c:585
>         context = 0x0
>         f = 0x0
>         old_font = 0x0

And this is a similar situation, just in a different place (see
bug#18659):

    if (context)
      {
	SelectObject (context, old_font);
	release_frame_dc (f, context);  <<<<<<<<<<<<<<<<<<<<<<
      }

As you see, if 'context' is a NULL pointer, release_frame_dc should
NOT be called.  And yet the locals in frame #2 above clearly show that
it _is_ NULL, and release_frame_dc _is_ called!

> #0  0x0000000100680609 in deselect_palette (f=0x0, hdc=0x0) at w32xfns.c:123
> No locals.
> #1  0x00000001006806d8 in release_frame_dc (f=0x0, hdc=0x0) at w32xfns.c:154
>         ret = 0
> #2  0x0000000100683d36 in uniscribe_encode_char (font=0x600b25360, c=48) at w32uniscribe.c:585
>         context = 0x0
>         f = 0x0
>         old_font = 0x0
>         code = 19

Same here.

IOW, these all exhibit the same bug, just in different places in the
Emacs sources.

Previous Next

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