From: Alan Mackenzie <acm@muc.de>
To: Chong Yidong <cyd@stupidchicken.com>
Cc: 7722@debbugs.gnu.org, Tassilo Horn <tassilo@member.fsf.org>
Subject: bug#7722: 24.0.50; Finding this C++ header file drops emacs into a infinite loop
Date: Sun, 13 Feb 2011 12:20:44 +0000 [thread overview]
Message-ID: <20110213122044.GB2078@muc.de> (raw)
In-Reply-To: <8739nu82od.fsf@stupidchicken.com>
Hi, Yidong!
On Fri, Feb 11, 2011 at 08:25:06PM -0500, Chong Yidong wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > It was indeed such a loop. It was caused by a 500n jit-lock boundary
> > falling in the middle of a template construct, hence the "necessity" of
> > all the whitespace to reproduce the failure.
> > Here's a putative patch for the problem. I've refactored the offending
> > function by replacing obscenely nested `if'-forms with a simple `cond'.
> > I've also removed some narrowing (to the 500n limit) which should help
> > jit-lock, hopefully without hurting too much elsewhere.
> > Tassilo, would you try out the patch, please, and let me know how it
> > goes. Thanks!
> Thanks. This patch doesn't apply cleanly to the emacs-23 branch.
That surprises me. Would you like me to rework the patch so that it
does?
> Do you think we could apply it to the trunk, and just use the
> workaround in the branch ....
To be honest, I haven't really looked at the workaround. I suppose it
would be OK. However, the patched version passed all the CC Mode
regression tests (which are about half indentation, half font-locking),
so I'm fairly confident about it.
> .... (some of these logic changes don't look obvious to me)?
One of the fixes was removing a `narrow-to-region' around the region
being fontified. In a jit-lock 500-byte chunk, this had the effect of
cutting necessary context off the end.
The other change was basically to refactor, in which the infinite looping
disappeared in the wash. Although I could get edebug going on this loop,
the source was just too complicated to be worthwhile trying to understand
in detail. (Believe me, I tried. :-)
Incidentally, I'm not getting mail from emacs-devel or bug-gnu-emacs at
the moment, and I've not got enough energy to do anything about it. Do
you know anything specific which might be doing this to me?
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2011-02-13 12:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-24 8:28 bug#7722: 24.0.50; Finding this C++ header file drops emacs into a infinite loop Tassilo Horn
2011-01-22 20:37 ` Chong Yidong
2011-01-27 0:55 ` Chong Yidong
2011-01-30 21:23 ` Daniel Colascione
2011-02-04 22:22 ` Alan Mackenzie
2011-02-06 19:20 ` Tassilo Horn
2011-02-12 1:25 ` Chong Yidong
2011-02-13 12:20 ` Alan Mackenzie [this message]
2011-02-13 20:41 ` Chong Yidong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110213122044.GB2078@muc.de \
--to=acm@muc.de \
--cc=7722@debbugs.gnu.org \
--cc=cyd@stupidchicken.com \
--cc=tassilo@member.fsf.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).