unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#34186: 26.1; locking up
@ 2019-01-23 16:24 Michael Menefee
  2019-01-24 14:45 ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Michael Menefee @ 2019-01-23 16:24 UTC (permalink / raw)
  To: 34186


Editing a C header file, I type
'#define AVL_iter(' and it locks up consistently and has to be killed
from another terminal, with CPU at 100%.



In GNU Emacs 26.1 (build 1, amd64-portbld-freebsd11.2)
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
avl.h has auto save data; consider M-x recover-this-file
Making completion list...

Configured using:
 'configure --disable-build-details --localstatedir=/var
 --with-gameuser=games:games --with-sound=no --without-cairo
 --without-dbus --without-gconf --without-gif --without-gsettings
 --with-x-toolkit=no --without-jpeg --without-lcms2 --without-m17n-flt
 --without-imagemagick --without-libotf --without-png
 --without-toolkit-scroll-bars --without-rsvg --without-tiff --without-x
 --without-xim --without-xpm --without-xwidgets --enable-acl
 --without-cairo --without-dbus --without-gconf --without-gif
 --with-gnutls --without-gsettings --without-jpeg --with-json
 --with-file-notification=kqueue --without-lcms2 --without-m17n-flt
 --without-imagemagick --with-mailutils --with-modules --without-libotf
 --without-png --without-toolkit-scroll-bars --without-rsvg
 --with-threads --without-tiff --without-xft --without-xim --with-xml2
 --without-xpm --without-xwidgets --with-x-toolkit=no
 --prefix=/usr/local --mandir=/usr/local/man --disable-silent-rules
 --infodir=/usr/local/share/emacs/info/
 --build=amd64-portbld-freebsd11.2 'CFLAGS=-O2 -pipe -fstack-protector
 -isystem /usr/local/include -fno-strict-aliasing ' 'CPPFLAGS=-isystem
 /usr/local/include' 'LDFLAGS= -fstack-protector -L/usr/local/lib ''

Configured features:
NOTIFY ACL GNUTLS LIBXML2 ZLIB MODULES THREADS

Important settings:
  locale-coding-system: nil

Major mode: C/*l

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
mml-sec password-cache epa derived epg epg-config gnus-util rmail
tool-bar rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils cc-mode cc-fonts easymenu cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs regexp-opt
cl-loaddefs cl-lib term/xterm xterm time-date elec-pair disp-table
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote kqueue multi-tty make-network-process emacs)

Memory information:
((conses 16 113912 7715)
 (symbols 48 21664 1)
 (miscs 40 37 117)
 (strings 32 33281 1470)
 (string-bytes 1 1017633)
 (vectors 16 14418)
 (vector-slots 8 469218 6278)
 (floats 8 50 318)
 (intervals 56 522 258)
 (buffers 992 13))





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#34186: 26.1; locking up
  2019-01-23 16:24 bug#34186: 26.1; locking up Michael Menefee
@ 2019-01-24 14:45 ` Eli Zaretskii
  2019-01-24 14:53   ` Michael Menefee
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2019-01-24 14:45 UTC (permalink / raw)
  To: Michael Menefee; +Cc: 34186

> From: Michael Menefee <mpmenefee@gmail.com>
> Date: Wed, 23 Jan 2019 10:24:09 -0600
> 
> Editing a C header file, I type
> '#define AVL_iter(' and it locks up consistently and has to be killed
> from another terminal, with CPU at 100%.

I cannot reproduce this.  Does the buffer contain anything else in
addition to the text you've shown?  Does it happen in "emacs -Q"?

I invoked "emacs -Q", then typed

  C-x C-f headerhang.h
  #define AVL_iter(

At that point, Emacs was responsive as I'd expect.  Are you doing the
same to reproduce the problem?

Thanks.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#34186: 26.1; locking up
  2019-01-24 14:45 ` Eli Zaretskii
@ 2019-01-24 14:53   ` Michael Menefee
  2019-01-24 16:32     ` Michael Menefee
  0 siblings, 1 reply; 7+ messages in thread
From: Michael Menefee @ 2019-01-24 14:53 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 34186

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

Hi,

I narrowed it down to a "#define anything(" as the last line in the buffer
will consistently lock up for me.  I'm sure it's the c mode not resolving
something right.  I will experiment more and send you the results if I can
reproduce with minimal buffer content.

Thanks

On Thu, Jan 24, 2019, 8:46 AM Eli Zaretskii <eliz@gnu.org wrote:

> > From: Michael Menefee <mpmenefee@gmail.com>
> > Date: Wed, 23 Jan 2019 10:24:09 -0600
> >
> > Editing a C header file, I type
> > '#define AVL_iter(' and it locks up consistently and has to be killed
> > from another terminal, with CPU at 100%.
>
> I cannot reproduce this.  Does the buffer contain anything else in
> addition to the text you've shown?  Does it happen in "emacs -Q"?
>
> I invoked "emacs -Q", then typed
>
>   C-x C-f headerhang.h
>   #define AVL_iter(
>
> At that point, Emacs was responsive as I'd expect.  Are you doing the
> same to reproduce the problem?
>
> Thanks.
>

[-- Attachment #2: Type: text/html, Size: 1482 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#34186: 26.1; locking up
  2019-01-24 14:53   ` Michael Menefee
@ 2019-01-24 16:32     ` Michael Menefee
  2019-01-24 17:41       ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Michael Menefee @ 2019-01-24 16:32 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 34186

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

I have found the minimum necessary to consistently reproduce.  copy/paste
this into *something.c* to see if you get same results:

void *AVL_first(AVL_t *);
void *AVL_last(AVL_t *);
#define (<--- locks up with pressing open parenthesis

Thanks


On Thu, Jan 24, 2019 at 8:53 AM Michael Menefee <mpmenefee@gmail.com> wrote:

> Hi,
>
> I narrowed it down to a "#define anything(" as the last line in the buffer
> will consistently lock up for me.  I'm sure it's the c mode not resolving
> something right.  I will experiment more and send you the results if I can
> reproduce with minimal buffer content.
>
> Thanks
>
> On Thu, Jan 24, 2019, 8:46 AM Eli Zaretskii <eliz@gnu.org wrote:
>
>> > From: Michael Menefee <mpmenefee@gmail.com>
>> > Date: Wed, 23 Jan 2019 10:24:09 -0600
>> >
>> > Editing a C header file, I type
>> > '#define AVL_iter(' and it locks up consistently and has to be killed
>> > from another terminal, with CPU at 100%.
>>
>> I cannot reproduce this.  Does the buffer contain anything else in
>> addition to the text you've shown?  Does it happen in "emacs -Q"?
>>
>> I invoked "emacs -Q", then typed
>>
>>   C-x C-f headerhang.h
>>   #define AVL_iter(
>>
>> At that point, Emacs was responsive as I'd expect.  Are you doing the
>> same to reproduce the problem?
>>
>> Thanks.
>>
>

[-- Attachment #2: Type: text/html, Size: 2382 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#34186: 26.1; locking up
  2019-01-24 16:32     ` Michael Menefee
@ 2019-01-24 17:41       ` Eli Zaretskii
  2019-01-24 18:06         ` Alan Mackenzie
  2019-01-25 16:30         ` Alan Mackenzie
  0 siblings, 2 replies; 7+ messages in thread
From: Eli Zaretskii @ 2019-01-24 17:41 UTC (permalink / raw)
  To: Michael Menefee, Alan Mackenzie; +Cc: 34186

> From: Michael Menefee <mpmenefee@gmail.com>
> Date: Thu, 24 Jan 2019 10:32:34 -0600
> Cc: 34186@debbugs.gnu.org
> 
> I have found the minimum necessary to consistently reproduce.  copy/paste this into something.c to see if you
> get same results:
> 
> void *AVL_first(AVL_t *);
> void *AVL_last(AVL_t *);
> #define (<--- locks up with pressing open parenthesis

Thanks, now I can reproduce this.  Alan, please take a look.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#34186: 26.1; locking up
  2019-01-24 17:41       ` Eli Zaretskii
@ 2019-01-24 18:06         ` Alan Mackenzie
  2019-01-25 16:30         ` Alan Mackenzie
  1 sibling, 0 replies; 7+ messages in thread
From: Alan Mackenzie @ 2019-01-24 18:06 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Michael Menefee, 34186

Hello, Eli.

On Thu, Jan 24, 2019 at 19:41:21 +0200, Eli Zaretskii wrote:
> > From: Michael Menefee <mpmenefee@gmail.com>
> > Date: Thu, 24 Jan 2019 10:32:34 -0600
> > Cc: 34186@debbugs.gnu.org

> > I have found the minimum necessary to consistently reproduce.  copy/paste this into something.c to see if you
> > get same results:

> > void *AVL_first(AVL_t *);
> > void *AVL_last(AVL_t *);
> > #define (<--- locks up with pressing open parenthesis

> Thanks, now I can reproduce this.  Alan, please take a look.

Will do!

Just as a matter of interest, it is not the same bug as #33784 (which
only occurred in the master branch).

-- 
Alan Mackenzie (Nuremberg, Germany).





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#34186: 26.1; locking up
  2019-01-24 17:41       ` Eli Zaretskii
  2019-01-24 18:06         ` Alan Mackenzie
@ 2019-01-25 16:30         ` Alan Mackenzie
  1 sibling, 0 replies; 7+ messages in thread
From: Alan Mackenzie @ 2019-01-25 16:30 UTC (permalink / raw)
  To: Eli Zaretskii, Michael Menefee; +Cc: 34186-done

Hello, Eli and Michael.

On Thu, Jan 24, 2019 at 19:41:21 +0200, Eli Zaretskii wrote:
> > From: Michael Menefee <mpmenefee@gmail.com>
> > Date: Thu, 24 Jan 2019 10:32:34 -0600
> > Cc: 34186@debbugs.gnu.org

> > I have found the minimum necessary to consistently reproduce.  copy/paste this into something.c to see if you
> > get same results:

> > void *AVL_first(AVL_t *);
> > void *AVL_last(AVL_t *);
> > #define (<--- locks up with pressing open parenthesis

> Thanks, now I can reproduce this.  Alan, please take a look.

I've committed the following fix to the emacs-26 branch.  I'm closing
the bug.

@Michael: This patch should apply cleanly to your Emacs 26.1 version (in
directory .../emacs/lisp/progmodes).  If you apply it, please
byte-compile the file before using it.  (If you want any help with the
patching and/or byte-compiling, feel free to send me private email.)



commit 9078f34e84178553cd59bc03ac1b58cb56038436
Author: Alan Mackenzie <acm@muc.de>
Date:   Fri Jan 25 16:14:00 2019 +0000

    Fix a loop in c-fl-decl-start.  This fixes bug #34186.
    
    * lisp/progmodes/cc-mode.el (c-fl-decl-start) In the pair of operations
    c-syntactic-skip-backward and c-forward-syntactic-ws, ensure the latter
    doesn't come back to the position before the former, and break out of the
    enclosing loop if it does.

diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el
index 8cbb4e8612..5283cfea6e 100644
--- a/lisp/progmodes/cc-mode.el
+++ b/lisp/progmodes/cc-mode.el
@@ -1487,6 +1487,7 @@ c-fl-decl-start
   ;; lock context (etc.) fontification.
   (goto-char pos)
   (let ((lit-start (c-literal-start))
+	old-pos
 	(new-pos pos)
 	capture-opener
 	bod-lim bo-decl)
@@ -1509,12 +1510,14 @@ c-fl-decl-start
     (while
 	;; Go to a less nested declaration each time round this loop.
 	(and
+	 (setq old-pos (point))
 	 (c-syntactic-skip-backward "^;{}" bod-lim t)
 	 (> (point) bod-lim)
 	 (progn (c-forward-syntactic-ws)
 		;; Have we got stuck in a comment at EOB?
 		(not (and (eobp)
 			  (c-literal-start))))
+	 (< (point) old-pos)
 	 (progn (setq bo-decl (point))
 		(or (not (looking-at c-protection-key))
 		    (c-forward-keyword-clause 1)))



-- 
Alan Mackenzie (Nuremberg, Germany).





^ permalink raw reply related	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2019-01-25 16:30 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-01-23 16:24 bug#34186: 26.1; locking up Michael Menefee
2019-01-24 14:45 ` Eli Zaretskii
2019-01-24 14:53   ` Michael Menefee
2019-01-24 16:32     ` Michael Menefee
2019-01-24 17:41       ` Eli Zaretskii
2019-01-24 18:06         ` Alan Mackenzie
2019-01-25 16:30         ` Alan Mackenzie

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).