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: Fri, 10 Oct 2014 10:19:57 +0300 [thread overview]
Message-ID: <837g08bdcy.fsf@gnu.org> (raw)
In-Reply-To: <e018b67b1a10448d3dd34ebe97682ab4@amuri.net>
> Date: Fri, 10 Oct 2014 15:21:53 +1300
> From: aidalgol@amuri.net
> Cc: Eli Zaretskii <eliz@gnu.org>, <kbrown@cornell.edu>
>
> > Could you show the disassembly of this function in its new form? I'd
> > like to see if the value of the bidi type being checked is loaded
> > into
> > the same register as in the original version.
>
> (gdb) disassemble 'bidi.c'::bidi_check_type
> Dump of assembler code for function bidi_check_type:
> 0x00000001004f9dd3 <+0>: push %rbp
> 0x00000001004f9dd4 <+1>: mov %rsp,%rbp
> 0x00000001004f9dd7 <+4>: sub $0x40,%rsp
> 0x00000001004f9ddb <+8>: mov %ecx,0x10(%rbp)
> 0x00000001004f9dde <+11>: mov 0x55d8db(%rip),%rax
> 0x00000001004f9de5 <+18>: movzbl (%rax),%eax
> 0x00000001004f9de8 <+21>: xor $0x1,%eax
> 0x00000001004f9deb <+24>: test %al,%al
> 0x00000001004f9ded <+26>: je 0x1004f9e37 <bidi_check_type+100>
> 0x00000001004f9def <+28>: cmpl $0x17,0x10(%rbp)
> 0x00000001004f9df3 <+32>: jbe 0x1004f9e37
Yes, this is the same arrangement as in the original version: passed
through ECX, then stored in RBP+0x10.
Moreover, the value printed by fprintf is taken from RBP+0x10:
> 0x00000001004f9dfa <+39>: mov 0x18(%rax),%rax
> 0x00000001004f9dfe <+43>: movl $0x17,0x30(%rsp)
> 0x00000001004f9e06 <+51>: movl $0x0,0x28(%rsp)
> 0x00000001004f9e0e <+59>: mov 0x10(%rbp),%edx <<<<<<<<<<<
> 0x00000001004f9e11 <+62>: mov %edx,0x20(%rsp) <<<<<<<<<<<
> 0x00000001004f9e15 <+66>: mov $0x14c,%r9d
> 0x00000001004f9e1b <+72>: lea 0x52edde(%rip),%r8
> 0x00000001004f9e22 <+79>: lea 0x52eddf(%rip),%rdx
> 0x00000001004f9e29 <+86>: mov %rax,%rcx
> 0x00000001004f9e2c <+89>: callq 0x1006b8080 <fprintf>
So now I'm no longer sure that my theory about some other thread
overwriting registers is valid. But what else could cause this?
Hm... can you try the following version instead? I expect it to force
GCC to store the value of 'type' in a 64-bit register, and use a
64-bit compare instruction for it. Please show the resulting
disassembly, so we are sure this trick succeeded.
=== modified file 'src/bidi.c'
--- src/bidi.c 2014-04-06 15:56:01 +0000
+++ src/bidi.c 2014-10-10 07:12:01 +0000
@@ -326,7 +326,14 @@ bidi_get_type (int ch, bidi_dir_t overri
static void
bidi_check_type (bidi_type_t type)
{
- eassert (UNKNOWN_BT <= type && type <= NEUTRAL_ON);
+ volatile ptrdiff_t qtype = type;
+
+ if (!(suppress_checking || (UNKNOWN_BT <= qtype && qtype <= NEUTRAL_ON)))
+ {
+ fprintf (stderr, "\r\n%s:%d: bidi type %d is not in [%d..%d]\r\n",
+ __FILE__, __LINE__, type, UNKNOWN_BT, NEUTRAL_ON);
+ emacs_abort ();
+ }
}
/* Given a bidi TYPE of a character, return its category. */
> > Also, if you have the backtrace, including from all the other
> > threads,
> > please post that.
>
> Attached, but the emacs process died while printing the backtrace for
> thread 2, and I have no idea why.
I do: it's because you started GDB from the src directory, where it
read the .gdbinit file, which causes the "bt" command to call a
function in the Emacs process being debugged.
To work around this, comment out (by prepending a # to every line) the
following few lines in .gdbinit:
define hookpost-backtrace
set $bt = backtrace_top ()
if backtrace_p ($bt)
echo \n
echo Lisp Backtrace:\n
xbacktrace
end
end
Then you will still be able to invoke "xbacktrace" by hand, but it
won't be invoked automatically by "bt".
Thanks.
next prev parent reply other threads:[~2014-10-10 7:19 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 [this message]
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
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=837g08bdcy.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).