GNU bug report logs - #2435
23.0.90; customize/whitespace: display stops updating

Previous Next

Package: emacs;

Reported by: Jindrich Makovicka <makovick <at> gmail.com>

Date: Sun, 22 Feb 2009 16:50:02 UTC

Severity: normal

Done: Chong Yidong <cyd <at> stupidchicken.com>

Bug is archived. No further changes may be made.

Full log


Message #45 received at 2435 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 2435 <at> debbugs.gnu.org
Subject: Re: Bug 2435
Date: Wed, 04 Mar 2009 11:16:53 +0900
In article <87zlg2a7b9.fsf <at> cyd.mit.edu>, Chong Yidong <cyd <at> 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 <at> m17n.org




This bug report was last modified 16 years and 135 days ago.

Previous Next


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