[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10664: 24.0.93; JIT font-lock infloops in a C file

From: Alan Mackenzie
Subject: bug#10664: 24.0.93; JIT font-lock infloops in a C file
Date: Tue, 7 Feb 2012 21:34:01 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Hello, Eli.

On Tue, Feb 07, 2012 at 10:58:09PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 7 Feb 2012 19:20:33 +0000
> > Cc: 10664@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > I've done a binary chop on this, and the following revision made this bug
> > apparent:

> > revno: 106729
> > committer: Alan Mackenzie <acm@muc.de>
> > branch nick: trunk
> > timestamp: Sat 2011-12-24 19:32:31 +0000
> > message:
> >   Introduce a mechanism to widen the region used in context font locking.
> >   Use this to protect declarations from losing their contexts.

> > I'll see what I can work out from this.  At least it's one of mine.  ;-)

> Great, thanks.

I understand what's happening, now.  The new code (from 2011-12-24),
given a point, is calculating a "safe" position backwards from that point
to start fontifying from.  This is a position which gives the correct
context for the original point.

For one particular fontification in socket.c, the "safe position" is 500
bytes back from the starting point, so jit-lock is pushed back these 500
bytes, fontifies the next 500 bytes (`jit-lock-chunk-size'), then has its
new start position set back 500 bytes, rinse, spin, repeat.

I don't understand yet why this isn't happening a lot more frequently.
I think it's got something to do with the safe position being _exactly_
500 bytes back.

I don't know what to do about this yet, but I'll think of something.

Good night!

Alan Mackenzie (Nuremberg, Germany).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]