bug#11841: 24.1; emacs hangs when opening cpp file with mixed eol styles

[Vadim K <vadimsks@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2990 bytes --]

Hello Alan,


I've tried your patch and it worked fine for the original posted bad.cpp
file. However I have found a variation of that file that still causes emacs
to hang (see attached bad2.cpp).


Vadim Kalviss

On Sat, Jul 21, 2012 at 12:10 AM, Alan Mackenzie <acm@muc.de> wrote:

> 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@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).
>

[-- Attachment #1.2: Type: text/html, Size: 4035 bytes --]

[-- Attachment #2: bad2.cpp --]
[-- Type: text/x-c++src, Size: 309 bytes --]


struct IsFNEq : public USE_STD::binary_function <SFileDesc, SFileDesc, bool>
{
   result_type operator( ) ( const first_argument_type& a, 
				 const second_argument_type& b ) const
   {
   }
};


void CA::Execute(CD *pCurState)
{

            		rsp.AddFileInfo(entry->d_name, st.st_size);
		}