bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18438: 24.4.50; assertion failed in bidi.c


From: Eli Zaretskii
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@amuri.net
> Cc: Ken Brown <kbrown@cornell.edu>, <18438@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]