From: Eli Zaretskii <eliz@gnu.org>
To: aidalgol@amuri.net
Cc: 18438@debbugs.gnu.org
Subject: bug#18438: 24.4.50; assertion failed in bidi.c
Date: Mon, 20 Oct 2014 18:46:13 +0300 [thread overview]
Message-ID: <83vbnebv7e.fsf@gnu.org> (raw)
In-Reply-To: <8fb0816e369e7468b2de862558dbbcbc@amuri.net>
> 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.
next prev parent reply other threads:[~2014-10-20 15:46 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-09 21:41 bug#18438: 24.4.50; assertion failed in bidi.c aidalgol
2014-09-10 0:16 ` Stefan Monnier
2014-09-10 18:55 ` Aidan Gauland
2014-09-10 19:09 ` Eli Zaretskii
2014-09-11 4:31 ` aidalgol
2014-09-11 13:18 ` Ken Brown
2014-09-12 1:51 ` aidalgol
2014-09-12 1:55 ` aidalgol
2014-09-12 6:00 ` Eli Zaretskii
2014-09-12 7:46 ` Eli Zaretskii
2014-09-16 1:04 ` aidalgol
2014-09-16 2:47 ` Eli Zaretskii
2014-09-16 2:59 ` aidalgol
2014-09-16 14:33 ` Eli Zaretskii
2014-09-16 22:42 ` aidalgol
2014-09-17 5:07 ` Eli Zaretskii
2014-09-18 4:55 ` aidalgol
2014-09-18 4:59 ` aidalgol
2014-09-18 14:42 ` Eli Zaretskii
2014-09-21 22:30 ` Ken Brown
2014-09-24 5:07 ` aidalgol
2014-09-24 14:06 ` Ken Brown
2014-09-24 15:01 ` Eli Zaretskii
2014-09-24 16:40 ` Ken Brown
2014-09-24 19:49 ` Eli Zaretskii
2014-09-28 23:03 ` aidalgol
2014-09-10 13:14 ` Ken Brown
2014-09-29 0:56 ` aidalgol
2014-09-29 6:23 ` Eli Zaretskii
2014-09-29 15:50 ` Ken Brown
2014-09-29 17:00 ` Eli Zaretskii
2014-09-29 22:28 ` aidalgol
2014-09-30 15:24 ` Eli Zaretskii
2014-09-30 16:09 ` Ken Brown
2014-09-30 16:27 ` Eli Zaretskii
2014-09-30 23:06 ` aidalgol
2014-10-01 2:39 ` Eli Zaretskii
2014-10-01 2:58 ` aidalgol
2014-10-01 14:42 ` Eli Zaretskii
2014-10-01 21:56 ` aidalgol
2014-10-01 2:40 ` Ken Brown
2014-10-08 22:20 ` aidalgol
2014-10-09 7:29 ` Eli Zaretskii
2014-10-10 2:21 ` aidalgol
2014-10-10 7:19 ` Eli Zaretskii
2014-10-10 7:26 ` Eli Zaretskii
2014-10-10 13:54 ` Ken Brown
2014-10-10 15:12 ` Eli Zaretskii
2014-10-10 17:14 ` Ken Brown
2014-10-11 1:57 ` Ken Brown
2014-10-11 7:11 ` Eli Zaretskii
2014-10-11 13:58 ` Ken Brown
2014-10-11 14:24 ` Eli Zaretskii
2014-10-11 16:33 ` Ken Brown
2014-10-11 16:52 ` Eli Zaretskii
2014-10-11 17:17 ` Ken Brown
2014-10-15 0:58 ` aidalgol
2014-10-15 5:13 ` Eli Zaretskii
2014-10-15 19:29 ` aidalgol
2014-10-16 7:27 ` Eli Zaretskii
2014-10-16 13:11 ` Ken Brown
2014-10-16 13:38 ` Eli Zaretskii
2014-10-19 14:39 ` Eli Zaretskii
2014-10-19 15:37 ` Ken Brown
2014-10-19 18:10 ` Eli Zaretskii
2014-10-19 19:49 ` aidalgol
2014-10-19 20:20 ` aidalgol
2014-10-20 15:46 ` Eli Zaretskii [this message]
2014-10-20 16:51 ` Eli Zaretskii
2014-10-20 19:35 ` Ivan Shmakov
2014-10-20 19:39 ` Eli Zaretskii
2014-10-20 20:02 ` Ivan Shmakov
2014-10-20 20:59 ` Ken Brown
2014-10-21 15:42 ` Eli Zaretskii
2014-10-21 16:18 ` Ken Brown
2014-10-21 19:38 ` aidalgol
2014-10-21 21:12 ` Ken Brown
2014-10-21 21:58 ` aidalgol
2014-10-21 22:21 ` Ken Brown
2014-10-21 22:38 ` aidalgol
2014-10-22 4:16 ` aidalgol
2014-10-22 15:24 ` Eli Zaretskii
2014-10-22 17:16 ` Eli Zaretskii
2014-10-22 20:39 ` Ken Brown
2014-10-23 20:38 ` aidalgol
2014-10-23 21:54 ` aidalgol
2014-10-24 6:50 ` Eli Zaretskii
2014-10-24 19:18 ` Ken Brown
2014-10-24 21:19 ` Ken Brown
2014-10-29 4:30 ` aidalgol
2014-10-29 12:15 ` Ken Brown
2014-10-29 14:37 ` Eli Zaretskii
2015-12-26 15:37 ` bug#17817: " Lars Ingebrigtsen
2015-12-26 15:43 ` Ken Brown
2014-10-29 14:17 ` Eli Zaretskii
2014-10-23 4:15 ` aidalgol
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83vbnebv7e.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=18438@debbugs.gnu.org \
--cc=aidalgol@amuri.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).