From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#7722: 24.0.50; Finding this C++ header file drops emacs into a infinite loop Date: Fri, 4 Feb 2011 22:22:07 +0000 Message-ID: <20110204222207.GA2424@muc.de> References: <87fwtnbmmj.fsf@member.fsf.org> <87hbd0y8sb.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1296858979 24656 80.91.229.12 (4 Feb 2011 22:36:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 4 Feb 2011 22:36:19 +0000 (UTC) Cc: 7722@debbugs.gnu.org, Tassilo Horn To: Chong Yidong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 04 23:36:13 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PlUGB-00053p-TV for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Feb 2011 23:36:13 +0100 Original-Received: from localhost ([127.0.0.1]:54225 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PlUGA-0006LI-Os for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Feb 2011 17:36:10 -0500 Original-Received: from [140.186.70.92] (port=38823 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PlUG1-0006I1-P1 for bug-gnu-emacs@gnu.org; Fri, 04 Feb 2011 17:36:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PlUG0-0003Lg-6k for bug-gnu-emacs@gnu.org; Fri, 04 Feb 2011 17:36:01 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42058) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PlUFs-0003Kv-UU; Fri, 04 Feb 2011 17:35:52 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PlTfF-0007UL-TX; Fri, 04 Feb 2011 16:58:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Fri, 04 Feb 2011 21:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7722 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 7722-submit@debbugs.gnu.org id=B7722.129685667828774 (code B ref 7722); Fri, 04 Feb 2011 21:58:01 +0000 Original-Received: (at 7722) by debbugs.gnu.org; 4 Feb 2011 21:57:58 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PlTfB-0007U3-IR for submit@debbugs.gnu.org; Fri, 04 Feb 2011 16:57:57 -0500 Original-Received: from colin.muc.de ([193.149.48.1] helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PlTf8-0007Tr-Qg for 7722@debbugs.gnu.org; Fri, 04 Feb 2011 16:57:56 -0500 Original-Received: (qmail 98766 invoked by uid 3782); 4 Feb 2011 22:06:26 -0000 Original-Received: from acm.muc.de (pD9E5293C.dip.t-dialin.net [217.229.41.60]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Fri, 04 Feb 2011 23:06:24 +0100 Original-Received: (qmail 4323 invoked by uid 1000); 4 Feb 2011 22:22:07 -0000 Content-Disposition: inline In-Reply-To: <87hbd0y8sb.fsf@stupidchicken.com> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 04 Feb 2011 16:58:01 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:43952 Archived-At: Hi there, Yidong, Tassilo, On Sat, Jan 22, 2011 at 03:37:24PM -0500, Chong Yidong wrote: > Tassilo Horn writes: > > Originally reported by Caligo > > He uses GNU Emacs 23.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1), > > but the bug in still in the current bzr trunk. > > 1. emacs -Q bug.hpp > > 2. emacs loops infinitely using 100% CPU resources > > The offending file is that (according to the original reporter, the > > spaces and empty lines are needed): > I can reproduce this (file attached for convenience). Alan, could you > take a look? Looks like a loop in c-forward-<>-arglist-recur: 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! === modified file 'lisp/progmodes/cc-engine.el' *** lisp/progmodes/cc-engine.el 2011-01-31 23:54:50 +0000 --- lisp/progmodes/cc-engine.el 2011-02-04 22:12:46 +0000 *************** *** 5455,5463 **** (goto-char start) nil)) ! (forward-char) (unless (looking-at c-<-op-cont-regexp) (while (and (progn (c-forward-syntactic-ws) --- 5455,5465 ---- (goto-char start) nil)) ! (forward-char) ; Forward over the opening '<'. (unless (looking-at c-<-op-cont-regexp) + ;; go forward one non-alphanumeric character (group) per iteration of + ;; this loop. (while (and (progn (c-forward-syntactic-ws) *************** *** 5486,5492 **** (c-forward-type) (c-forward-syntactic-ws)))))) ! (setq pos (point)) ;; Note: These regexps exploit the match order in \| so ;; that "<>" is matched by "<" rather than "[^>:-]>". --- 5488,5494 ---- (c-forward-type) (c-forward-syntactic-ws)))))) ! (setq pos (point)) ; e.g. first token inside the '<' ;; Note: These regexps exploit the match order in \| so ;; that "<>" is matched by "<" rather than "[^>:-]>". *************** *** 5522,5559 **** ;; Either an operator starting with '<' or a nested arglist. (setq pos (point)) (let (id-start id-end subres keyword-match) ! (if (if (looking-at c-<-op-cont-regexp) ! (setq tmp (match-end 0)) ! (setq tmp pos) ! (backward-char) ! (not ! (and ! ! (save-excursion ! ;; There's always an identifier before an angle ! ;; bracket arglist, or a keyword in ! ;; `c-<>-type-kwds' or `c-<>-arglist-kwds'. ! (c-backward-syntactic-ws) ! (setq id-end (point)) ! (c-simple-skip-symbol-backward) ! (when (or (setq keyword-match ! (looking-at c-opt-<>-sexp-key)) ! (not (looking-at c-keywords-regexp))) ! (setq id-start (point)))) ! ! (setq subres ! (let ((c-promote-possible-types t) ! (c-record-found-types t)) ! (c-forward-<>-arglist-recur ! (and keyword-match ! (c-keyword-member ! (c-keyword-sym (match-string 1)) ! 'c-<>-type-kwds))))) ! ))) ! ! ;; It was not an angle bracket arglist. ! (goto-char tmp) ! ;; It was an angle bracket arglist. (setq c-record-found-types subres) --- 5524,5558 ---- ;; Either an operator starting with '<' or a nested arglist. (setq pos (point)) (let (id-start id-end subres keyword-match) ! (cond ! ;; The '<' begins a multi-char operator. ! ((looking-at c-<-op-cont-regexp) ! (setq tmp (match-end 0)) ! (goto-char (match-end 0))) ! ;; We're at a nested <.....> ! ((progn ! (setq tmp pos) ! (backward-char) ; to the '<' ! (and ! (save-excursion ! ;; There's always an identifier before an angle ! ;; bracket arglist, or a keyword in `c-<>-type-kwds' ! ;; or `c-<>-arglist-kwds'. ! (c-backward-syntactic-ws) ! (setq id-end (point)) ! (c-simple-skip-symbol-backward) ! (when (or (setq keyword-match ! (looking-at c-opt-<>-sexp-key)) ! (not (looking-at c-keywords-regexp))) ! (setq id-start (point)))) ! (setq subres ! (let ((c-promote-possible-types t) ! (c-record-found-types t)) ! (c-forward-<>-arglist-recur ! (and keyword-match ! (c-keyword-member ! (c-keyword-sym (match-string 1)) ! 'c-<>-type-kwds))))))) ;; It was an angle bracket arglist. (setq c-record-found-types subres) *************** *** 5567,5574 **** (c-forward-syntactic-ws) (looking-at c-opt-identifier-concat-key))) (c-record-ref-id (cons id-start id-end)) ! (c-record-type-id (cons id-start id-end)))))) ! t) ((and (not c-restricted-<>-arglists) (or (and (eq (char-before) ?&) --- 5566,5578 ---- (c-forward-syntactic-ws) (looking-at c-opt-identifier-concat-key))) (c-record-ref-id (cons id-start id-end)) ! (c-record-type-id (cons id-start id-end))))) ! ! ;; At a "less than" operator. ! (t ! (forward-char) ! ))) ! t) ; carry on looping. ((and (not c-restricted-<>-arglists) (or (and (eq (char-before) ?&) === modified file 'lisp/progmodes/cc-fonts.el' *** lisp/progmodes/cc-fonts.el 2011-01-25 04:08:28 +0000 --- lisp/progmodes/cc-fonts.el 2011-02-04 22:10:01 +0000 *************** *** 1082,1088 **** (boundp 'parse-sexp-lookup-properties)))) ;; Below we fontify a whole declaration even when it crosses the limit, ! ;; to avoid gaps when lazy-lock fontifies the file a screenful at a ;; time. That is however annoying during editing, e.g. the following is ;; a common situation while the first line is being written: ;; --- 1082,1088 ---- (boundp 'parse-sexp-lookup-properties)))) ;; Below we fontify a whole declaration even when it crosses the limit, ! ;; to avoid gaps when jit/lazy-lock fontifies the file a block at a ;; time. That is however annoying during editing, e.g. the following is ;; a common situation while the first line is being written: ;; *************** *** 1094,1102 **** ;; "some_other_variable" as an identifier, and the latter will not ;; correct itself until the second line is changed. To avoid that we ;; narrow to the limit if the region to fontify is a single line. ! (narrow-to-region ! (point-min) ! (if (<= limit (c-point 'bonl)) (save-excursion ;; Narrow after any operator chars following the limit though, ;; since those characters can be useful in recognizing a --- 1094,1102 ---- ;; "some_other_variable" as an identifier, and the latter will not ;; correct itself until the second line is changed. To avoid that we ;; narrow to the limit if the region to fontify is a single line. ! (if (<= limit (c-point 'bonl)) ! (narrow-to-region ! (point-min) (save-excursion ;; Narrow after any operator chars following the limit though, ;; since those characters can be useful in recognizing a *************** *** 1104,1111 **** ;; after the header). (goto-char limit) (skip-chars-forward c-nonsymbol-chars) ! (point)) ! limit)) (c-find-decl-spots limit --- 1104,1110 ---- ;; after the header). (goto-char limit) (skip-chars-forward c-nonsymbol-chars) ! (point)))) (c-find-decl-spots limit -- Alan Mackenzie (Nuremberg, Germany).