GNU bug report logs - #28233
CC Mode 5.33 (C/*l); Emacs may get stuck with 100% CPU

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28233 in the body.
You can then email your comments to 28233 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mohammed Sadiq <sadiq <at> sadiqpk.org>
To: submit <at> debbugs.gnu.org
Subject: CC Mode 5.33 (C/*l); Emacs may get stuck with 100% CPU
Date: Fri, 25 Aug 2017 21:00:52 +0530

Emacs always get stuck when writing some code (given below), using 100 % CPU for
(probably) limitless time:

How to reproduce:

1. Open a new empty file: emacs -Q test.c
2. Write the following (| is where the point is)
   #include<|
3. Delete the content: C-a C-k
4. Try to write the same again:
   #include<|

Result:
  At the 4th step, after typing #,GNU Emacs begins to use full CPU and
  does nothing. Though this can be cancelled using C-g.


Emacs  : GNU Emacs 26.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2017-08-25
Package: CC Mode 5.33 (C/*l)
Buffer Style: gnu
c-emacs-features: (pps-extended-state col-0-paren posix-char-classes gen-string-delim gen-comment-delim syntax-properties 1-bit)

current state:
==============
(setq
 c-basic-offset 2
 c-comment-only-line-offset '(0 . 0)
 c-indent-comment-alist '((anchored-comment column . 0) (end-block space . 1)
			  (cpp-end-block space . 2))
 c-indent-comments-syntactically-p nil
 c-block-comment-prefix ""
 c-comment-prefix-regexp '((pike-mode . "//+!?\\|\\**") (awk-mode . "#+")
			   (other . "//+\\|\\**"))
 c-doc-comment-style '((java-mode . javadoc) (pike-mode . autodoc)
		       (c-mode . gtkdoc))
 c-cleanup-list '(scope-operator)
 c-hanging-braces-alist '((substatement-open before after)
			  (arglist-cont-nonempty))
 c-hanging-colons-alist nil
 c-hanging-semi&comma-criteria '(c-semi&comma-inside-parenlist)
 c-backslash-column 48
 c-backslash-max-column 72
 c-special-indent-hook '(c-gnu-impose-minimum)
 c-label-minimum-indentation 1
 c-offsets-alist '((inexpr-class . +)
		   (inexpr-statement . +)
		   (lambda-intro-cont . +)
		   (inlambda . c-lineup-inexpr-block)
		   (template-args-cont c-lineup-template-args +)
		   (incomposition . +)
		   (inmodule . +)
		   (innamespace . +)
		   (inextern-lang . +)
		   (composition-close . 0)
		   (module-close . 0)
		   (namespace-close . 0)
		   (extern-lang-close . 0)
		   (composition-open . 0)
		   (module-open . 0)
		   (namespace-open . 0)
		   (extern-lang-open . 0)
		   (objc-method-call-cont
		    c-lineup-ObjC-method-call-colons
		    c-lineup-ObjC-method-call
		    +
		    )
		   (objc-method-args-cont . c-lineup-ObjC-method-args)
		   (objc-method-intro . [0])
		   (friend . 0)
		   (cpp-define-intro c-lineup-cpp-define +)
		   (cpp-macro-cont . +)
		   (cpp-macro . [0])
		   (inclass . +)
		   (stream-op . c-lineup-streamop)
		   (arglist-cont-nonempty
		    c-lineup-gcc-asm-reg
		    c-lineup-arglist
		    )
		   (arglist-cont c-lineup-gcc-asm-reg 0)
		   (comment-intro c-lineup-knr-region-comment c-lineup-comment)
		   (catch-clause . 0)
		   (else-clause . 0)
		   (do-while-closure . 0)
		   (access-label . -)
		   (case-label . 0)
		   (substatement . +)
		   (statement-case-intro . +)
		   (statement . 0)
		   (brace-entry-open . 0)
		   (brace-list-entry . c-lineup-under-anchor)
		   (brace-list-close . 0)
		   (block-close . 0)
		   (block-open . 0)
		   (inher-cont . c-lineup-multi-inher)
		   (inher-intro . +)
		   (member-init-cont . c-lineup-multi-inher)
		   (member-init-intro . +)
		   (annotation-var-cont . +)
		   (annotation-top-cont . 0)
		   (topmost-intro . 0)
		   (knr-argdecl . 0)
		   (func-decl-cont . +)
		   (inline-close . 0)
		   (class-close . 0)
		   (class-open . 0)
		   (defun-block-intro . +)
		   (defun-close . 0)
		   (defun-open . 0)
		   (c . c-lineup-C-comments)
		   (string . c-lineup-dont-change)
		   (topmost-intro-cont
		    first
		    c-lineup-topmost-intro-cont
		    c-lineup-gnu-DEFUN-intro-cont
		    )
		   (brace-list-intro . c-lineup-arglist-intro-after-paren)
		   (brace-list-open . +)
		   (inline-open . 0)
		   (arglist-close . c-lineup-arglist)
		   (arglist-intro . c-lineup-arglist-intro-after-paren)
		   (statement-cont . +)
		   (statement-case-open . +)
		   (label . 0)
		   (substatement-label . 0)
		   (substatement-open . +)
		   (knr-argdecl-intro . 5)
		   (statement-block-intro . +)
		   )
 c-buffer-is-cc-mode 'c-mode
 c-tab-always-indent t
 c-syntactic-indentation t
 c-syntactic-indentation-in-macros t
 c-ignore-auto-fill '(string cpp code)
 c-auto-align-backslashes t
 c-backspace-function 'backward-delete-char-untabify
 c-delete-function 'delete-char
 c-electric-pound-behavior nil
 c-default-style '((java-mode . "java") (awk-mode . "awk") (other . "gnu"))
 c-enable-xemacs-performance-kludge-p nil
 c-old-style-variable-behavior nil
 defun-prompt-regexp nil
 tab-width 8
 comment-column 32
 parse-sexp-ignore-comments t
 parse-sexp-lookup-properties t
 auto-fill-function nil
 comment-multi-line t
 comment-start-skip "\\(//+\\|/\\*+\\)\\s *"
 fill-prefix nil
 fill-column 70
 paragraph-start "[ 	]*\\(//+\\|\\**\\)[ 	]*$\\|^\f"
 adaptive-fill-mode t
 adaptive-fill-regexp "[ 	]*\\(//+\\|\\**\\)[ 	]*\\([ 	]*\\([-–!|#%;>*·•‣⁃◦]+[ 	]*\\)*\\)"
 )

Message #8 received at 28233 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Mohammed Sadiq <sadiq <at> sadiqpk.org>
Cc: 28233 <at> debbugs.gnu.org
Subject: Re: bug#28233: CC Mode 5.33 (C/*l); Emacs may get stuck with 100% CPU
Date: Sat, 26 Aug 2017 17:29:06 +0000

Hello, Mohammed.

On Fri, Aug 25, 2017 at 21:00:52 +0530, Mohammed Sadiq wrote:


> Emacs always get stuck when writing some code (given below), using 100 % CPU for
> (probably) limitless time:

> How to reproduce:

> 1. Open a new empty file: emacs -Q test.c
> 2. Write the following (| is where the point is)
>    #include<|
> 3. Delete the content: C-a C-k
> 4. Try to write the same again:
>    #include<|

> Result:
>   At the 4th step, after typing #,GNU Emacs begins to use full CPU and
>   does nothing. Though this can be cancelled using C-g.

Yes.  There is a bug in some cache handling code for macros, which
results in that cache thinking there's still a macro after it's been
deleted.

Thanks indeed for the bug report!

Would you please apply the following patch, then confirm to me that it's
fixed the problem, or else tell me what's still not working.  Thanks!



diff -r dbf1a31b3959 cc-engine.el
--- a/cc-engine.el	Tue Aug 22 16:38:44 2017 +0000
+++ b/cc-engine.el	Sat Aug 26 17:24:49 2017 +0000
@@ -250,7 +250,7 @@
   ;; Called from a before-change function.  If the change region is before or
   ;; in the macro characterized by `c-macro-cache' etc., nullify it
   ;; appropriately.  BEG and END are the standard before-change-functions
-  ;; parameters.  END isn't used.
+  ;; parameters.
   (cond
    ((null c-macro-cache))
    ((< beg (car c-macro-cache))
@@ -258,6 +258,12 @@
 	  c-macro-cache-start-pos nil
 	  c-macro-cache-syntactic nil
 	  c-macro-cache-no-comment nil))
+   ((and (= beg (car c-macro-cache))
+	 (> end beg))
+    (setq c-macro-cache nil
+	  c-macro-cache-start-pos nil
+	  c-macro-cache-syntactic nil
+	  c-macro-cache-no-comment nil))
    ((and (cdr c-macro-cache)
 	 (< beg (cdr c-macro-cache)))
     (setcdr c-macro-cache nil)


[ CC Mode configuration dump appreciated, but snipped. ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #11 received at 28233 <at> debbugs.gnu.org (full text, mbox):

From: Mohammed Sadiq <sadiq <at> sadiqpk.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 28233 <at> debbugs.gnu.org
Subject: Re: bug#28233: CC Mode 5.33 (C/*l); Emacs may get stuck with 100% CPU
Date: Sun, 27 Aug 2017 06:54:11 +0530 (IST)

> On August 26, 2017 at 10:59 PM Alan Mackenzie <acm <at> muc.de> wrote:
> 
> 
> Hello, Mohammed.
> 
Hi


> Yes.  There is a bug in some cache handling code for macros, which
> results in that cache thinking there's still a macro after it's been
> deleted.
> 
> Thanks indeed for the bug report!
> 
> Would you please apply the following patch, then confirm to me that it's
> fixed the problem, or else tell me what's still not working.  Thanks!
> 
 <snipped>

The patch surely fixed the issue. Thanks

By the way, the patch wasn't applying to the current HEAD of emacs git. I had to
manually add those lines it. Is it built from some other source? Alternatively,
can I say patch to skip some n lines (positive or negative) than the ones said in diff
and try to apply?

Message #16 received at 28233-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Mohammed Sadiq <sadiq <at> sadiqpk.org>
Cc: 28233-done <at> debbugs.gnu.org
Subject: Re: bug#28233: CC Mode 5.33 (C/*l); Emacs may get stuck with 100% CPU
Date: Sun, 27 Aug 2017 10:47:16 +0000

Hello, Mohammed.

On Sun, Aug 27, 2017 at 06:54:11 +0530, Mohammed Sadiq wrote:

> > On August 26, 2017 at 10:59 PM Alan Mackenzie <acm <at> muc.de> wrote:


> > Hello, Mohammed.

> Hi


> > Yes.  There is a bug in some cache handling code for macros, which
> > results in that cache thinking there's still a macro after it's been
> > deleted.

> > Thanks indeed for the bug report!

> > Would you please apply the following patch, then confirm to me that it's
> > fixed the problem, or else tell me what's still not working.  Thanks!

>  <snipped>

> The patch surely fixed the issue. Thanks

I actually committed a rather simpler patch.  The problem was "merely" an
off-by-1 bug, but in the same function.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #19 received at 28233 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Mohammed Sadiq <sadiq <at> sadiqpk.org>
Cc: 28233 <at> debbugs.gnu.org
Subject: Re: bug#28233: CC Mode 5.33 (C/*l); Emacs may get stuck with 100% CPU
Date: Sun, 27 Aug 2017 10:57:32 +0000

Hello again, Mohammed.

On Sun, Aug 27, 2017 at 06:54:11 +0530, Mohammed Sadiq wrote:

[ .... ]

> The patch surely fixed the issue. Thanks

> By the way, the patch wasn't applying to the current HEAD of emacs git.
> I had to manually add those lines it. Is it built from some other
> source? Alternatively, can I say patch to skip some n lines (positive
> or negative) than the ones said in diff and try to apply?

Sorry about that.  I fixed the bug, and created the patch in standalone
CC Mode, so the line numbers do differ a bit.  However, I checked that
the patch would apply to the Emacs sources before sending it to you, by:

    $ patch --dry-run < ~/path/to/diff.20170826.diff

in the Emacs .../lisp/progmodes directory.  This `patch' is the standard
GNU utility, with $ patch --version returning:

    GNU patch 2.7.5
    Copyright (C) 2003, 2009-2012 Free Software Foundation, Inc.
    Copyright (C) 1988 Larry Wall

.  It copes fine with the line numbers in the patch and the target file
being a little adrift, or with there being extraneous text present (such
as when patch is presented with an entire email as a patch file).

Which patch utility are you using?

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #22 received at 28233 <at> debbugs.gnu.org (full text, mbox):

From: Mohammed Sadiq <sadiq <at> sadiqpk.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 28233 <at> debbugs.gnu.org
Subject: Re: bug#28233: CC Mode 5.33 (C/*l); Emacs may get stuck with 100% CPU
Date: Sun, 27 Aug 2017 21:53:41 +0530 (IST)

> On August 27, 2017 at 4:27 PM Alan Mackenzie <acm <at> muc.de> wrote:
> 
> 
> Hello again, Mohammed.

Hello


> Which patch utility are you using?

 Just like most other tools, I'm using the GNU project's patch with version
2.7.5

It seems like my mail client have mangled the spaces in the patch given.
Sorry for the noise.

-- Mohammed Sadiq

Previous Next

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