GNU bug report logs -
#18438
24.4.50; assertion failed in bidi.c
Previous Next
Reported by: aidalgol <at> amuri.net
Date: Tue, 9 Sep 2014 21:52:01 UTC
Severity: normal
Tags: moreinfo
Merged with 17817
Found in versions 24.3.91, 24.4.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #208 received at 18438 <at> debbugs.gnu.org (full text, mbox):
> 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.
This bug report was last modified 9 years and 154 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.