GNU bug report logs - #18438
24.4.50; assertion failed in bidi.c

Previous Next

Full log

View this message in rfc822 format

From: aidalgol <at> amuri.net
To: <18438 <at> debbugs.gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, kbrown <at> cornell.edu
Subject: bug#18438: 24.4.50; assertion failed in bidi.c
Date: Fri, 10 Oct 2014 15:21:53 +1300

[Message part 1 (text/plain, inline)]

Resending to list, because I hit the wrong reply button the first time. 
Apologies.

On Thu, 09 Oct 2014 10:29:50 +0300, Eli Zaretskii wrote:
>
>> OK, it finally happened.  It printed out...
>>
>> bidi.c:332: bidi type 22 is not in [0..23]
>
> Bidi type 22 is whitespace, most likely the SPC character.
>
>> Isn't that a logical impossibility?
>
> Of course, it is.  It always was.  This is what this bug is all 
> about.
>
>> What the hell is going on?
>
> That's what we are trying to establish.  My working hypothesis is 
> that
> some unrelated code, either in another Emacs thread or maybe (less
> likely) in the OS bowels preempts this function and doesn't restore
> all the registers when it passes control back to the function.  Any
> other ideas are welcome.
>
> 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        # 
0x100a576c0 <.refptr.suppress_checking>
   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 
<bidi_check_type+100>
   0x00000001004f9df5 <+34>:    callq  0x1006b7d00 <__getreent>
   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        # 
0x100a28c00 <DEFAULT_REHASH_SIZE+56>
   0x00000001004f9e22 <+79>:    lea    0x52eddf(%rip),%rdx        # 
0x100a28c08 <DEFAULT_REHASH_SIZE+64>
   0x00000001004f9e29 <+86>:    mov    %rax,%rcx
   0x00000001004f9e2c <+89>:    callq  0x1006b8080 <fprintf>
   0x00000001004f9e31 <+94>:    callq  0x100665e15 <emacs_abort>
   0x00000001004f9e36 <+99>:    nop
   0x00000001004f9e37 <+100>:   add    $0x40,%rsp
   0x00000001004f9e3b <+104>:   pop    %rbp
   0x00000001004f9e3c <+105>:   retq
End of assembler dump.


> 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.

Since the first time I sent this (to only Eli, see above), I rebooted, 
and got the assert again, and was able to get a backtrace (attached) 
from another thread, but it died printing the backtrace of the same 
thread as last time.

[backtrace (text/plain, attachment)]

[emacs-b8497de-patched-bidi-01.backtrace (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.