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

From: Ken Brown <[email-masked]>
Date: Fri, 10 Oct 2014 09:54:18 -0400

On 10/10/2014 3:19 AM, Eli Zaretskii wrote:
> === 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.  */

It works:

Dump of assembler code for function bidi_check_type:
    0x00000001004fc423 <+0>:     push   %rbp
    0x00000001004fc424 <+1>:     mov    %rsp,%rbp
    0x00000001004fc427 <+4>:     sub    $0x50,%rsp
    0x00000001004fc42b <+8>:     mov    %ecx,0x10(%rbp)
    0x00000001004fc42e <+11>:    mov    0x10(%rbp),%eax
    0x00000001004fc431 <+14>:    mov    %rax,-0x8(%rbp)
    0x00000001004fc435 <+18>:    mov    0x56bfb4(%rip),%rax        # 0x100a683f0 
<.refptr.suppress_checking>
    0x00000001004fc43c <+25>:    movzbl (%rax),%eax
    0x00000001004fc43f <+28>:    xor    $0x1,%eax
    0x00000001004fc442 <+31>:    test   %al,%al
    0x00000001004fc444 <+33>:    je     0x1004fc49b <bidi_check_type+120>
    0x00000001004fc446 <+35>:    mov    -0x8(%rbp),%rax
    0x00000001004fc44a <+39>:    test   %rax,%rax   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    0x00000001004fc44d <+42>:    js     0x1004fc459 <bidi_check_type+54>
    0x00000001004fc44f <+44>:    mov    -0x8(%rbp),%rax
    0x00000001004fc453 <+48>:    cmp    $0x17,%rax  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    0x00000001004fc457 <+52>:    jle    0x1004fc49b <bidi_check_type+120>
    0x00000001004fc459 <+54>:    callq  0x1006c6a50 <__getreent>
    0x00000001004fc45e <+59>:    mov    0x18(%rax),%rax
    0x00000001004fc462 <+63>:    movl   $0x17,0x30(%rsp)
    0x00000001004fc46a <+71>:    movl   $0x0,0x28(%rsp)
    0x00000001004fc472 <+79>:    mov    0x10(%rbp),%edx
    0x00000001004fc475 <+82>:    mov    %edx,0x20(%rsp)
    0x00000001004fc479 <+86>:    mov    $0x14d,%r9d
    0x00000001004fc47f <+92>:    lea    0x53b16a(%rip),%r8        # 0x100a375f0 
<DEFAULT_REHASH_SIZE+56>
    0x00000001004fc486 <+99>:    lea    0x53b16b(%rip),%rdx        # 0x100a375f8 
<DEFAULT_REHASH_SIZE+64>
    0x00000001004fc48d <+106>:   mov    %rax,%rcx
    0x00000001004fc490 <+109>:   callq  0x1006c6d70 <fprintf>
    0x00000001004fc495 <+114>:   callq  0x100672ebc <emacs_abort>
    0x00000001004fc49a <+119>:   nop
    0x00000001004fc49b <+120>:   add    $0x50,%rsp
    0x00000001004fc49f <+124>:   pop    %rbp
    0x00000001004fc4a0 <+125>:   retq
End of assembler dump.

Do you have a new theory that this is testing?

Ken