[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10913: 24.0.94; Crash in redisplay code
From: |
Jan Djärv |
Subject: |
bug#10913: 24.0.94; Crash in redisplay code |
Date: |
Wed, 29 Feb 2012 22:23:48 +0100 |
29 feb 2012 kl. 19:34 skrev Eli Zaretskii:
>> From: Hannu Koivisto <azure@iki.fi>
>> Date: Wed, 29 Feb 2012 18:12:35 +0200
>>
>> Random crash. I don't know how to reproduce this. Backtrace included
>> below. Some string variable contents have been changed from what
>> they really were.
>
> This is an optimized build, right? Otherwise, some variables shown
> here make no sense at all. E.g., this:
>
>> #3 0x010873f3 in fast_looking_at (regexp=6, pos=676026, pos_byte=96427,
>> limit=89596416, limit_byte=285891, string=1) at search.c:588
>
> `regexp' is a Lisp string, so it cannot have this value. And `pos'
> and `limit' are likewise garbled.
>
> Anyway, if I'm to believe this backtrace (which I don't, since the
> build is evidently optimized), the crash happened here:
>
> switch (SWITCH_ENUM_CAST ((re_opcode_t) *pat++))
> {
> case on_failure_keep_string_jump:
> assert (str == NULL);
> goto continue_failure_jump;
>
> case on_failure_jump_nastyloop:
> assert ((re_opcode_t)pat[-2] == no_op);
> PUSH_FAILURE_POINT (pat - 2, str);
> /* Fallthrough */
> ...
> default:
> abort (); <<<<<<<<<<<<<<<<<<<<<
> }
>
> which means what? that compile_pattern produced an invalid result?
> I'd be surprised.
Remember that optimization may join aborts together, so they look like they
happened there, but it can be just about any abort in that file.
Jan D.