[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#2435: Bug 2435
From: |
Kenichi Handa |
Subject: |
bug#2435: Bug 2435 |
Date: |
Wed, 04 Mar 2009 11:16:53 +0900 |
In article <87zlg2a7b9.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com>
writes:
>>> emacs -Q
>>> M-x customize-group RET whitespace RET
>>> C-v C-v
> >
> > I can't reproduce the crash with that.
> It doesn't happen all the time---about once every three or four
> attempts. Quite strange.
I tried more than 10 times without crash.
> > 2846 if (many_times_ok)
> > 2847 {
> > 2848 boolean simple = skip_one_char (laststart)
> > == b;
> > 2849 unsigned int startoffset = 0;
> > 2850 re_opcode_t ofj =
> > 2851 /* Check if the loop can match the empty
> > string. */
> > 2852 (simple || !analyse_first (laststart, b,
> > NULL, 0))
> > 2853 ? on_failure_jump : on_failure_jump_loop;
> >
> > Here, "simple" is always set to 1, so analyse_first is not
> > called.
> When I get the crash, simple is set to 0.
> (gdb) p b
> $4 = (unsigned char *) 0x8b927b7 ""
> (gdb) p laststart
> $5 = (unsigned char *) 0x8b92786 "\a\201\f"
That is different in my case. When the execution reaches
the above code (three or four times while displaying that
Tibetan char), laststart is always "\004\200". Here the
first byte \004 means `charset' OP, and that is reasonable
because we are now handling '*' after "[...]".
But '\a' (== 7 == stop_memory) is very strange. Please show
me these values when simple is set to 0.
(gdb) p bufp->buffer
$58 = (unsigned char *) 0xa905aa0 "\004\200"
(gdb) p laststart
$59 = (unsigned char *) 0xa905ab2 "\004\200"
(gdb) p bufp->buffer[0]@(b - bufp->buffer)
$60 =
"\004\200\000\000\002\000@\017\000i\017\000j\017\000j\017\000\004\200\000\000\004\000\220\017\000\271\017\000\272\017\000\272\017\000\273\017\000\273\017\000\274\017\000\274\017"
(gdb) p laststart[0]@(b-laststart)
$61 =
"\004\200\000\000\004\000\220\017\000\271\017\000\272\017\000\272\017\000\273\017\000\273\017\000\274\017\000\274\017"
Here,
"\220\017\000" => 0xF90
"\271\017\000" => 0xFB9
"\272\017\000" => 0xFBA
"\273\017\000" => 0xFBB
"\274\017\000" => 0xFBC
So, we are now processing the '*' just after the second
[...] of tibetan-composable-pattern.
---
Kenichi Handa
handa@m17n.org
- bug#2435: Bug 2435, Chong Yidong, 2009/03/03
- bug#2435: Bug 2435,
Kenichi Handa <=
- bug#2435: Bug 2435, Chong Yidong, 2009/03/04
- bug#2435: Bug 2435, Chong Yidong, 2009/03/05
- bug#2435: Bug 2435, Kenichi Handa, 2009/03/05
- bug#2435: Bug 2435, Stefan Monnier, 2009/03/05
- bug#2435: Bug 2435, Kenichi Handa, 2009/03/05
- bug#2435: Bug 2435, Chong Yidong, 2009/03/05
- bug#2435: Bug 2435, Kenichi Handa, 2009/03/06