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

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

[Vadim K]

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

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. The error occurs on a Windows XP SP3,
with default emacs settings (no .emacs file).


In GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600)
 of 2012-06-10 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x C-f C-g M-x r e p o r t - e m <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win
w32-vars tool-bar dnd fontset image fringe lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process multi-tty emacs)

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

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

IMPLEMENT_DYNCREATE (C1, B1)

struct S1
{
	CStr	m_strFileName;
	UInt32	m_iSize;
};

struct S2 : public USE_STD::binary_function <S1, S1, bool>
{
};


void C1::Aaaaaaa(CAaaaaaaaa *pA)
{
                {
                    m_logger->LogMessage(DL_WARNING, ROUTINE_NAME, "invalid type of the file '" + name + "'");

                }
                {
                    m_logger->LogMessage(DL_WARNING, ROUTINE_NAME, "invalid type of the file '" + name + "'");
                }
}

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

[Eli Zaretskii]

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


#0  0x010e6192 in Fforward_comment (count=-4) at syntax.c:2257
2257      count1 = XINT (count);
(gdb) bt
#0  0x010e6192 in Fforward_comment (count=-4) at syntax.c:2257
#1  0x01036fa0 in Ffuncall (nargs=2, args=0x8890b4) at eval.c:2820
#2  0x011217b8 in exec_byte_code (bytestr=55905377, vector=56389925,
    maxdepth=28, args_template=54007834, nargs=0, args=0x0) at bytecode.c:784
#3  0x01037ec9 in funcall_lambda (fun=54714693, nargs=0, arg_vector=0x889318)
    at eval.c:3052
#4  0x010373a7 in Ffuncall (nargs=1, args=0x889314) at eval.c:2869
#5  0x011217b8 in exec_byte_code (bytestr=78719425, vector=56727821,
    maxdepth=12, args_template=54007834, nargs=0, args=0x0) at bytecode.c:784
#6  0x01037ec9 in funcall_lambda (fun=56418309, nargs=0, arg_vector=0x889568)
    at eval.c:3052
#7  0x010373a7 in Ffuncall (nargs=1, args=0x889564) at eval.c:2869
#8  0x011217b8 in exec_byte_code (bytestr=56747153, vector=56729493,
    maxdepth=20, args_template=54007834, nargs=0, args=0x0) at bytecode.c:784
#9  0x01120d72 in Fbyte_code (bytestr=56747153, vector=56729493, maxdepth=20)
    at bytecode.c:423
#10 0x01035176 in eval_sub (form=54295206) at eval.c:2173
#11 0x010326cb in internal_catch (tag=54281082, func=0x103479b <eval_sub>,
    arg=54295206) at eval.c:1090
#12 0x0112200c in exec_byte_code (bytestr=56747425, vector=54052669,
    maxdepth=24, args_template=54007834, nargs=0, args=0x0) at bytecode.c:965
#13 0x01037ec9 in funcall_lambda (fun=54716845, nargs=2, arg_vector=0x889af8)
    at eval.c:3052
#14 0x010373a7 in Ffuncall (nargs=3, args=0x889af4) at eval.c:2869
#15 0x011217b8 in exec_byte_code (bytestr=56796849, vector=79242501,
    maxdepth=36, args_template=54007834, nargs=0, args=0x0) at bytecode.c:784
#16 0x01120d72 in Fbyte_code (bytestr=56796849, vector=79242501, maxdepth=36)
    at bytecode.c:423
#17 0x01035176 in eval_sub (form=54249310) at eval.c:2173
#18 0x010326cb in internal_catch (tag=54280842, func=0x103479b <eval_sub>,
    arg=54249310) at eval.c:1090
#19 0x0112200c in exec_byte_code (bytestr=56814689, vector=56344581,
    maxdepth=108, args_template=54007834, nargs=0, args=0x0) at bytecode.c:965
#20 0x01037ec9 in funcall_lambda (fun=54717941, nargs=3, arg_vector=0x88a0e8)
    at eval.c:3052
#21 0x010373a7 in Ffuncall (nargs=4, args=0x88a0e4) at eval.c:2869
#22 0x011217b8 in exec_byte_code (bytestr=57055425, vector=56474525,
    maxdepth=24, args_template=54007834, nargs=0, args=0x0) at bytecode.c:784
#23 0x01120d72 in Fbyte_code (bytestr=57055425, vector=56474525, maxdepth=24)
    at bytecode.c:423
#24 0x01035176 in eval_sub (form=57289462) at eval.c:2173
#25 0x010326cb in internal_catch (tag=55802314, func=0x103479b <eval_sub>,
    arg=57289462) at eval.c:1090
#26 0x0112200c in exec_byte_code (bytestr=57055489, vector=54719949,
    maxdepth=8, args_template=54007834, nargs=0, args=0x0) at bytecode.c:965
#27 0x01037ec9 in funcall_lambda (fun=56474701, nargs=0, arg_vector=0x88a668)
    at eval.c:3052
#28 0x010373a7 in Ffuncall (nargs=1, args=0x88a664) at eval.c:2869
#29 0x011217b8 in exec_byte_code (bytestr=79061969, vector=79266485,
    maxdepth=20, args_template=54007834, nargs=0, args=0x0) at bytecode.c:784
#30 0x01037ec9 in funcall_lambda (fun=79266565, nargs=1, arg_vector=0x88a8c8)
    at eval.c:3052
#31 0x010373a7 in Ffuncall (nargs=2, args=0x88a8c4) at eval.c:2869
#32 0x011217b8 in exec_byte_code (bytestr=20931777, vector=20932029,
    maxdepth=36, args_template=54007834, nargs=0, args=0x0) at bytecode.c:784
#33 0x01037ec9 in funcall_lambda (fun=20931749, nargs=3, arg_vector=0x88ab38)
    at eval.c:3052
#34 0x010373a7 in Ffuncall (nargs=4, args=0x88ab34) at eval.c:2869
#35 0x011217b8 in exec_byte_code (bytestr=20927449, vector=20927621,
    maxdepth=20, args_template=54007834, nargs=0, args=0x0) at bytecode.c:784
#36 0x01037ec9 in funcall_lambda (fun=20927405, nargs=3, arg_vector=0x88ad98)
    at eval.c:3052
#37 0x010373a7 in Ffuncall (nargs=4, args=0x88ad94) at eval.c:2869
#38 0x011217b8 in exec_byte_code (bytestr=79036049, vector=78949733,
    maxdepth=16, args_template=54007834, nargs=0, args=0x0) at bytecode.c:784
#39 0x01037ec9 in funcall_lambda (fun=78949797, nargs=3, arg_vector=0x88aff8)
    at eval.c:3052
#40 0x010373a7 in Ffuncall (nargs=4, args=0x88aff4) at eval.c:2869
#41 0x011217b8 in exec_byte_code (bytestr=20925777, vector=20925829,
    maxdepth=16, args_template=54007834, nargs=0, args=0x0) at bytecode.c:784
#42 0x01037ec9 in funcall_lambda (fun=20925717, nargs=2, arg_vector=0x88b38c)
    at eval.c:3052
#43 0x010373a7 in Ffuncall (nargs=3, args=0x88b388) at eval.c:2869
#44 0x01035f49 in funcall_nil (nargs=3, args=0x88b388) at eval.c:2337
#45 0x010363b2 in run_hook_with_args (nargs=3, args=0x88b388,
    funcall=0x1035f31 <funcall_nil>) at eval.c:2526
#46 0x01035fc1 in Frun_hook_with_args (nargs=3, args=0x88b388) at eval.c:2387
#47 0x01036d0c in Ffuncall (nargs=4, args=0x88b384) at eval.c:2802
#48 0x011217b8 in exec_byte_code (bytestr=20397313, vector=20941677,
    maxdepth=16, args_template=54007834, nargs=0, args=0x0) at bytecode.c:784
#49 0x01120d72 in Fbyte_code (bytestr=20397313, vector=20941677, maxdepth=16)
    at bytecode.c:423
#50 0x01035176 in eval_sub (form=20941630) at eval.c:2173
#51 0x01032c02 in internal_lisp_condition_case (var=54191898,
    bodyform=20941630, handlers=20941702) at eval.c:1287
#52 0x01122073 in exec_byte_code (bytestr=20941241, vector=20941405,
    maxdepth=32, args_template=54007834, nargs=0, args=0x0) at bytecode.c:980
#53 0x01037ec9 in funcall_lambda (fun=20941213, nargs=2, arg_vector=0x88b968)
    at eval.c:3052
#54 0x010373a7 in Ffuncall (nargs=3, args=0x88b964) at eval.c:2869
#55 0x011217b8 in exec_byte_code (bytestr=20940809, vector=20940933,
    maxdepth=40, args_template=54007834, nargs=0, args=0x0) at bytecode.c:784
#56 0x01037ec9 in funcall_lambda (fun=20940781, nargs=1, arg_vector=0x88bcf4)
    at eval.c:3052
#57 0x010373a7 in Ffuncall (nargs=2, args=0x88bcf0) at eval.c:2869
#58 0x0103304a in internal_condition_case_n (bfun=0x103693f <Ffuncall>,
    nargs=2, args=0x88bcf0, handlers=54007858,
    hfun=0x1158ec5 <safe_eval_handler>) at eval.c:1455
#59 0x01158f61 in safe_call (nargs=2, args=0x88bcf0) at xdisp.c:2411
#60 0x01158fa3 in safe_call1 (fn=55803050, arg=2008) at xdisp.c:2430
#61 0x0115c003 in handle_fontified_prop (it=0x88c9d0) at xdisp.c:3594
#62 0x0115b0b5 in handle_stop (it=0x88c9d0) at xdisp.c:3158
#63 0x01169ddb in next_element_from_buffer (it=0x88c9d0) at xdisp.c:7836
#64 0x01165b23 in get_next_display_element (it=0x88c9d0) at xdisp.c:6501
#65 0x011910d0 in display_line (it=0x88c9d0) at xdisp.c:19224
#66 0x01186bbf in try_window (window=56188421, pos=..., flags=1)
    at xdisp.c:16217
#67 0x01184448 in redisplay_window (window=56188421, just_this_one_p=0)
    at xdisp.c:15743
#68 0x0117d759 in redisplay_window_0 (window=56188421) at xdisp.c:13813
#69 0x01032e1c in internal_condition_case_1 (
    bfun=0x117d727 <redisplay_window_0>, arg=56188421, handlers=53992294,
    hfun=0x117d706 <redisplay_window_error>) at eval.c:1371
#70 0x0117d6f6 in redisplay_windows (window=56188421) at xdisp.c:13793
#71 0x0117b62f in redisplay_internal () at xdisp.c:13366
#72 0x0117880e in redisplay () at xdisp.c:12575
#73 0x0100884a in read_char (commandflag=1, nmaps=2, maps=0x88fa00,
    prev_event=54007834, used_mouse_menu=0x88fb2c, end_time=0x0)
    at keyboard.c:2452
#74 0x0101c5f6 in read_key_sequence (keybuf=0x88fc30, bufsize=30,
    prompt=54007834, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:9338
#75 0x01005aca in command_loop_1 () at keyboard.c:1450
#76 0x01032d0c in internal_condition_case (bfun=0x10054d8 <command_loop_1>,
    handlers=54058490, hfun=0x1004ce0 <cmd_error>) at eval.c:1333
#77 0x0100511c in command_loop_2 (ignore=54007834) at keyboard.c:1155
#78 0x010326cb in internal_catch (tag=54048322,
    func=0x10050f9 <command_loop_2>, arg=54007834) at eval.c:1090
#79 0x010050d4 in command_loop () at keyboard.c:1134
#80 0x0100469e in recursive_edit_1 () at keyboard.c:754
#81 0x010049c0 in Frecursive_edit () at keyboard.c:818
#82 0x010027eb in main (argc=2, argv=0xce1938) at emacs.c:1693

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)

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

[Stefan Monnier]

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

(setq font-lock-support-mode nil) should hopefully make it possible to
debug it more conveniently from Elisp.


        Stefan

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

[Alan Mackenzie]

Hi, Eli.

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.


> #0  0x010e6192 in Fforward_comment (count=-4) at syntax.c:2257
> 2257      count1 = XINT (count);
[ ..... ]

> Lisp Backtrace:
> "forward-comment" (0x8890b8)
> "c-backward-sws" (0x889318)
[ .... ]

Just as an observation, (forward-comment -1) doesn't move back over a ^M.
I think it should.  This might be the cause of the observed bad
behaviour.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier]

> Just as an observation, (forward-comment -1) doesn't move back over a ^M.

Why should it?  It's not a whitespace, and while it has "comment end"
syntax, it does not have a matching comment-start.

I think you should give it whitespace syntax.
Currently "foo // bar ^M baz ^J" is treated in CC-mode as "foo <comment>
baz", which I think is wrong.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Eli Zaretskii <eliz@gnu.org>, 11841@debbugs.gnu.org,
>         Vadim K <vadimsks@gmail.com>
> Date: Sat, 07 Jul 2012 17:53:47 -0400
> 
> > Just as an observation, (forward-comment -1) doesn't move back over a ^M.
> 
> Why should it?  It's not a whitespace, and while it has "comment end"
> syntax, it does not have a matching comment-start.
> 
> I think you should give it whitespace syntax.
> Currently "foo // bar ^M baz ^J" is treated in CC-mode as "foo <comment>
> baz", which I think is wrong.

Perhaps so, but in the file in question you have ^M^J with northing
between them.  So a lone ^M is not an issue here.

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

[Stefan Monnier]

>> > Just as an observation, (forward-comment -1) doesn't move back over a ^M.
>> 
>> Why should it?  It's not a whitespace, and while it has "comment end"
>> syntax, it does not have a matching comment-start.
>> 
>> I think you should give it whitespace syntax.
>> Currently "foo // bar ^M baz ^J" is treated in CC-mode as "foo <comment>
>> baz", which I think is wrong.

> Perhaps so, but in the file in question you have ^M^J with northing
> between them.  So a lone ^M is not an issue here.

Yes it is: without a "//" in front of it, a ^M is not a comment-ender
and syntax.c then treats it as a "strange char" (for \n used as comment
ender, syntax.c knows to treat it as whitespace when there's no
matching comment-starter, but that's a special case, for other chars
this is not so, e.g. for pascal's } it would be wrong to treat it as
whitespace).


        Stefan

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

[Alan Mackenzie]

Hello, Stefan.

On Sun, Jul 08, 2012 at 10:50:03AM -0400, Stefan Monnier wrote:
> >> > Just as an observation, (forward-comment -1) doesn't move back over a ^M.

> >> Why should it?  It's not a whitespace, and while it has "comment end"
> >> syntax, it does not have a matching comment-start.

> >> I think you should give it whitespace syntax.
> >> Currently "foo // bar ^M baz ^J" is treated in CC-mode as "foo <comment>
> >> baz", which I think is wrong.

I've tried setting ^M's syntax to WS.  The code no longer loops.
However, ^M is syntactically a comment ender so that it can end a comment
when selective-display is active.

> > Perhaps so, but in the file in question you have ^M^J with northing
> > between them.  So a lone ^M is not an issue here.

> Yes it is: without a "//" in front of it, a ^M is not a comment-ender
> and syntax.c then treats it as a "strange char" (for \n used as comment
> ender, syntax.c knows to treat it as whitespace when there's no
> matching comment-starter, but that's a special case, for other chars
> this is not so, e.g. for pascal's } it would be wrong to treat it as
> whitespace).

Would it not be better for ^M to be treated as WS by syntax.c?  The
current problem isn't really a CC Mode one; mixed line enders could
happen in a file of any major mode.  Emacs really ought to treat all line
endings the same.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier]

> I've tried setting ^M's syntax to WS.  The code no longer loops.
> However, ^M is syntactically a comment ender so that it can end a comment
> when selective-display is active.

^M is only a comment ender when selective-display is active.  So only
set its syntax to comment-end when selective-display is active.
Better yet: stop supporting selective-display.

> Would it not be better for ^M to be treated as WS by syntax.c?  The
> current problem isn't really a CC Mode one; mixed line enders could
> happen in a file of any major mode.  Emacs really ought to treat all line
> endings the same.

It does: it maps them all to ^J.
^M in a buffer is not a line-ender (except for the oddball case of
selective-display which is a feature that needs to die).


        Stefan

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

[Alan Mackenzie]

Hello again, Stefan.

On Sun, Jul 08, 2012 at 07:07:41PM -0400, Stefan Monnier wrote:
> > I've tried setting ^M's syntax to WS.  The code no longer loops.
> > However, ^M is syntactically a comment ender so that it can end a
> > comment when selective-display is active.

> ^M is only a comment ender when selective-display is active.  So only
> set its syntax to comment-end when selective-display is active.

Is that possible?  If so, is it possible without introducing horrible
couplings between disparate bits of code..

> Better yet: stop supporting selective-display.

That's more a decision for the Emacs boss.  selective-display is still
supported in Emacs 24, according to the elisp manual.

> > Would it not be better for ^M to be treated as WS by syntax.c?  The
> > current problem isn't really a CC Mode one; mixed line enders could
> > happen in a file of any major mode.  Emacs really ought to treat all
> > line endings the same.

> It does: it maps them all to ^J.

It does not, except in normal cases.  When most, but not all, line
endings are CRLFs, they are not converted to LFs.  (To do so would lose
information.)

We could have philosophical arguments about whether a CRLF really is a
line ending in this case.  I think, that in practice, an MS-DOS source
file containing an isolated LF (created by some other editor) is the
normal abuse-case for this scenario.  It is causing problems.

> ^M in a buffer is not a line-ender (except for the oddball case of
> selective-display which is a feature that needs to die).

How about treating ^M^J as WS in syntax.c?  At the very least, in
forward-comment?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier]

>> Better yet: stop supporting selective-display.
> That's more a decision for the Emacs boss.

Not at all.  Any package is allowed to decide it won't support
interaction with some other package/feature.

> selective-display is still supported in Emacs 24, according to the
> elisp manual.

Yes, tho barely.  Some of the reason is that marking the variable
obsolete would also make obsolete the case where selective-display is
a number, even tho there is no replacement for that one.
The only case that I'd like to make obsolete is the case where
selective-display is set to t.

>> > Would it not be better for ^M to be treated as WS by syntax.c?  The
>> > current problem isn't really a CC Mode one; mixed line enders could
>> > happen in a file of any major mode.  Emacs really ought to treat all
>> > line endings the same.
>> It does: it maps them all to ^J.
> It does not, except in normal cases.  When most, but not all, line
> endings are CRLFs, they are not converted to LFs.  (To do so would lose
> information.)

This is philosophical: in the buffer, line-ends are ^J and never
anything else (except selective-display).  Whether that corresponds to
what is in the file or not is a completely different issue.

> How about treating ^M^J as WS in syntax.c?

Not gonna happen,


        Stefan

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

[Alan Mackenzie]

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

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

[Stefan Monnier]

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

Hard to believe you'd prefer such an ugly workaround instead of just
fixing the syntax of ^M.


        Stefan

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

[Vadim K]

[-- 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);
		}

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

[Alan Mackenzie]

Bug fixed in revision #111024.

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.

-- 
Alan Mackenzie (Nuremberg, Germany).