bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build)

[Ken Brown <kbrown@cornell.edu>]

On 6/20/2014 3:21 PM, Eli Zaretskii wrote:
>> Date: Fri, 20 Jun 2014 14:42:05 +0100
>> From: Ken Brown <kbrown@cornell.edu>
>>
>> I just got the following assertion failure:
>>
>>     bidi.c:329: Emacs fatal error: assertion failed: UNKNOWN_BT <= type
>> && type <= NEUTRAL_ON
>
> Is this the same 64-bit Cygwin-w32 build that was reported lately to
> produce nonsensical backtraces?

Yes.

>> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:351
>> No locals.
>> #1  0x00000001005ba95d in die (
>>      msg=0x100a2e538 <DEFAULT_REHASH_SIZE+64> "UNKNOWN_BT <= type && type <= NEUTRAL_ON", file=0x100a2e530 <DEFAULT_REHASH_SIZE+56> "bidi.c", line=329)
>>      at alloc.c:6826
>> No locals.
>> #2  0x00000001004fb4fe in bidi_check_type (type=STRONG_L) at bidi.c:329
>> No locals.
>> #3  0x0000000100500630 in bidi_level_of_next_char (bidi_it=0x2267d8)
>>      at bidi.c:2430
>>          type = STRONG_L
>>          level = 0
>>          prev_level = 0
>>          next_for_neutral = {
>>            bytepos = 0,
>>            charpos = -1,
>>            type = UNKNOWN_BT,
>>            type_after_w1 = UNKNOWN_BT,
>>            orig_type = UNKNOWN_BT
>>          }
>>          next_char_pos = 1
>
> This makes no sense at all: STRONG_L is one of the bidi types defined
> by 'enum bidi_type_t' (see dispextern.h), and therefore its value
> _must_ be between UNKNOWN_BT (whose value is zero) and NEUTRAL_ON, the
> last tag in the enumeration type.
>
> Can you see the numerical value of 'type' in frame #2?  Like this:
>
>   (gdb) fr 2
>   (gdb) p type + 0
 > Also, using a similar technique, display the values of UNKNOWN_BT and
 > of NEUTRAL_ON.

(gdb) p type + 0
$2 = 1
(gdb) p UNKNOWN_BT + 0
$3 = 0
(gdb) p NEUTRAL_ON + 0
$4 = 23

So, as you said, this is nonsense.

Ken