GNU bug report logs - #11841
24.1; emacs hangs when opening cpp file with mixed eol styles

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11841 <at> debbugs.gnu.org, Vadim K <vadimsks <at> gmail.com>
Subject: bug#11841: 24.1;	emacs hangs when opening cpp file with mixed eol styles
Date: Fri, 20 Jul 2012 21:10:46 +0000

Hello, Eli and Vadim.

On Mon, Jul 02, 2012 at 07:42:11PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 1 Jul 2012 20:51:43 -0400
> > From: Vadim K <vadimsks <at> gmail.com>

> > Emacs hangs forever with 100% cpu usage when I'm trying to open a
> > specific cpp file (see attached bad.cpp). The bad.cpp file has
> > Windows end of line style (0D 0A) everywhere except in the line next
> > to the last one.

> Inconsistent EOL format is not the problem, it is just the trigger.
> The problem seems to be that the C Mode is unable to process a buffer
> where some lines end in a ^M^J (a.k.a. CRLF) instead of a mere LF
> (newline).  To see that, make the EOL format of the test file
> consistently CRLF, then do this:

>   emacs -Q
>   M-x find-file-literally RET bad.cpp RET
>   M-x normal-mode

> Emacs will hang.

> I attached a debugger and produced the backtrace below.  By doing
> "finish" until it hanged, I found out that it infloops inside
> c-backward-sws.  HTH.


> Lisp Backtrace:
> "forward-comment" (0x8890b8)
> "c-backward-sws" (0x889318)
> "c-at-macro-vsemi-p" (0x889568)
> "byte-code" (0x889740)
> "c-crosses-statement-barrier-p" (0x889af8)
> "byte-code" (0x889ce0)
> "c-beginning-of-statement-1" (0x88a0e8)
> "byte-code" (0x88a2c0)
> "c-beginning-of-decl-1" (0x88a668)
> "c-font-lock-enclosing-decls" (0x88a8c8)
> "font-lock-fontify-keywords-region" (0x88ab38)
> "font-lock-default-fontify-region" (0x88ad98)
> "c-font-lock-fontify-region" (0x88aff8)
> "font-lock-fontify-region" (0x88b38c)
> "run-hook-with-args" (0x88b388)
> "byte-code" (0x88b560)
> "jit-lock-fontify-now" (0x88b968)
> "jit-lock-function" (0x88bcf4)

The following patch should, I hope, fix the problem.  Vadim, would you
try it out, please, and report back..


diff -r 1adcc48506f9 cc-engine.el
--- a/cc-engine.el	Sun Apr 22 09:42:29 2012 +0000
+++ b/cc-engine.el	Fri Jul 20 20:52:39 2012 +0000
@@ -1455,7 +1455,12 @@
 	    (not (bobp))
 
 	    (if (let (open-paren-in-column-0-is-defun-start)
-		  (forward-comment -1))
+		  (or (forward-comment -1)
+		      ;; Cope specifically with ^M^J here -
+		      ;; forward-comment gets stuck at ^Ms.
+		      (and (eq (char-before) ?\r)
+			   (progn (backward-char)
+				  (forward-comment -1)))))
 		(if (looking-at "\\*/")
 		    ;; Emacs <= 20 and XEmacs move back over the
 		    ;; closer of a block comment that lacks an opener.


-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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