Auto-completion results in runaway emacs process in emacs 24.4 on Debian using 2016-04-23-5f6855e-vpo #1070

veripoolbot · 2016-06-23T20:53:09Z

Author Name: Ian Perryman
Original Redmine Issue: 1070 from https://www.veripool.org

I was attempting to use the auto completion which is bound to M-?

I have a very small example, hopefully no need for an attachement.

I am using:
You are using verilog-mode 2016-04-23-5f6855e-vpo

On a debian system:
Linux desk-02 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u6 (2015-11-09) x86_64 GNU/Linux

Using Emacs
GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5) of 2015-03-07 on trouble, modified by Debian

Example file "moo.sv"

module moo; ini

I put cursor at end of second line (right after the ini)

I press M-? to complete "ini".

A buffer Completions" comes up with "initial" in it.

I select "initial" with a left-mouse click.

Completions buffer disappears, but my source file is unmodified.

The CPU pegs at 100% for the emacs process in top.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27864 iperrym+ 20 0 676308 234784 28768 R 100.3 1.5 1:25.21 emacs

Left unchecked the process will eventually exhaust all memory and die. Sometimes taking machine down with it.

The process seems to be in the background since emacs continues to operate fine (ie. I can continue to edit the file without much difficulty until the memory runs out (about 5 or 10 minutes)

Hitting "C-g" successfully kills the process.

veripoolbot · 2016-06-23T21:05:41Z

Original Redmine Comment
Author Name: Ian Perryman
Original Date: 2016-06-23T21:05:41Z

Here is the TOP output better formatted. Note CPU is at 100%, and %MEM will grow.


  PID USER     PR NIVIRT   RES    SHR   S %CPU  %MEM TIME+   COMMAND     
27864 iperrym+ 20 0 676308 234784 28768 R 100.3 1.5  1:25.21 emacs

veripoolbot · 2016-06-24T12:50:13Z

Original Redmine Comment
Author Name: Ian Perryman
Original Date: 2016-06-24T12:50:13Z

I just tried the same example on Windows 7 with an older version I had installed there.

GNU Emacs 24.5.1 (x86_64-w64-mingw32) of 2015-05-16 on KAEL
Using verilog-mode version 2015-12-01-a4a2f25-vpo

Similar results ... although CPU does not go to 100%, just to 15% but memory increases without bound until process is killed with C-g.

More details of the Laptop from systeminfo

OS Name:                   Microsoft Windows 7 Ultimate
OS Version:                6.1.7601 Service Pack 1 Build 7601
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free
System Manufacturer:       SAMSUNG ELECTRONICS CO., LTD.
System Model:              RF511/RF411/RF711
System Type:               x64-based PC
Processor(s):              1 Processor(s) Installed.
                            [01]: Intel64 Family 6 Model 42 Stepping 7 GenuineIntel ~2001 Mhz
BIOS Version:              American Megatrends Inc. 12HX.M037.20110616.SSH, 16/06/2011
Total Physical Memory:     8,104 MB
Available Physical Memory: 4,748 MB
Virtual Memory: Max Size:  16,207 MB
Virtual Memory: Available: 8,984 MB

veripoolbot · 2016-06-24T14:51:08Z

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2016-06-24T14:51:08Z

I get a emacs error.

Can you please do M-x eval-expression (setq debug-on-quit t)

then quickly after the hang hit ctrl-g and attach the resulting Backtrace buffer?

I apologize in advance as it might take a bit of time to get back to you with a fix on this.

veripoolbot · 2016-06-24T15:22:21Z

Original Redmine Comment
Author Name: Ian Perryman
Original Date: 2016-06-24T15:22:21Z

I tried following you directions, but it did not seem to work.

When I pressed C-g, I did not get a backtrace.

I alternately tried the menu "Options->Enter DEbugger on Quit/C-g"

After invoking the issue by pressing "M-?" then selecting "initial" with the left mouse, I would see the emacs session go to 100% in top, but C-g still did not create a back trace. Seems odd.

Tried to go into debugger before pressing M-? and it did not work then either.

Note the "Quit" message shows up in the Messages buffer, and the process that causes the cpu to peg at 100% are stopped. Just the debugger does not come up. The same behaviour was observed in the Win 7 environment also.

Here is the Messages buffer contents:

For information about GNU Emacs and the GNU system, type C-h C-a.
Gathering files...
Computing completion candidates... [2 times]
Debug on Quit enabled globally
Type SPC to continue editing.
Quit [20 times]
Type SPC to continue editing.
Quit [22 times]
Quit

veripoolbot · 2016-06-24T16:22:43Z

Original Redmine Comment
Author Name: Ian Perryman
Original Date: 2016-06-24T16:22:43Z

After fiddling around I tried this recipe:

I caused the problem using "M-?" and selected "initial" with left mouse.

Control goes back to emacs (what ever process that is causing 100% CPU must be a separate thread)

I then used M-x eval-expression (debug)

This dropped me into the debugger. I then stepped through the code.

I notice a loop where the stack frame goes through

Let me paste the loop that I see ... I think there are about 35-40 steps

Perhaps somehow in an infinite loop over font-lock?

Debugger entered--beginning evaluation of function call form:
* (normal-top-level)

Debugger entered--entering a function:
* message("Back to top level.")
* normal-top-level()

Debugger entered--returning value: "Back to top level."
  message("Back to top level.")
* normal-top-level()

Debugger entered--returning value: "Back to top level."
  normal-top-level()

Debugger entered--entering a function:
* global-font-lock-mode-check-buffers()

Debugger entered--entering a function:
* global-font-lock-mode-enable-in-buffers()
* global-font-lock-mode-check-buffers()

Debugger entered--entering a function:
* buffer-live-p(#<buffer *Backtrace*>)
* global-font-lock-mode-enable-in-buffers()
* global-font-lock-mode-check-buffers()

Debugger entered--returning value: t
  buffer-live-p(#<buffer *Backtrace*>)
* global-font-lock-mode-enable-in-buffers()
* global-font-lock-mode-check-buffers()

Debugger entered--returning value: nil
  global-font-lock-mode-enable-in-buffers()
* global-font-lock-mode-check-buffers()

Debugger entered--entering a function:
* remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--entering a function:
* boundp(post-command-hook)
* remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--returning value: t
  boundp(post-command-hook)
* remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--entering a function:
* default-boundp(post-command-hook)
* remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--returning value: t
  default-boundp(post-command-hook)
* remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--entering a function:
* local-variable-p(post-command-hook)
* remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--returning value: nil
  local-variable-p(post-command-hook)
* remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--entering a function:
* default-value(post-command-hook)
* remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--returning value: (global-font-lock-mode-check-buffers debugger-reenable)
  default-value(post-command-hook)
* remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--entering a function:
* copy-sequence((global-font-lock-mode-check-buffers debugger-reenable))
* remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--returning value: (global-font-lock-mode-check-buffers debugger-reenable)
  copy-sequence((global-font-lock-mode-check-buffers debugger-reenable))
* remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--entering a function:
* delete(global-font-lock-mode-check-buffers (global-font-lock-mode-check-buffers debugger-reenable))
* remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--returning value: (debugger-reenable)
  delete(global-font-lock-mode-check-buffers (global-font-lock-mode-check-buffers debugger-reenable))
* remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--entering a function:
* set-default(post-command-hook (debugger-reenable))
* remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--returning value: (debugger-reenable)
  set-default(post-command-hook (debugger-reenable))
* remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--returning value: (debugger-reenable)
  remove-hook(post-command-hook global-font-lock-mode-check-buffers)
* global-font-lock-mode-check-buffers()

Debugger entered--returning value: (debugger-reenable)
  global-font-lock-mode-check-buffers()

Debugger entered--entering a function:
* debugger-reenable()

Debugger entered--entering a function:
* remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--entering a function:
* boundp(post-command-hook)
* remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--returning value: t
  boundp(post-command-hook)
* remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--entering a function:
* default-boundp(post-command-hook)
* remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--returning value: t
  default-boundp(post-command-hook)
* remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--entering a function:
* local-variable-p(post-command-hook)
* remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--returning value: nil
  local-variable-p(post-command-hook)
* remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--entering a function:
* default-value(post-command-hook)
* remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--returning value: (global-font-lock-mode-check-buffers debugger-reenable)
  default-value(post-command-hook)
* remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--entering a function:
* copy-sequence((global-font-lock-mode-check-buffers debugger-reenable))
* remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--returning value: (global-font-lock-mode-check-buffers debugger-reenable)
  copy-sequence((global-font-lock-mode-check-buffers debugger-reenable))
* remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--entering a function:
* delete(debugger-reenable (global-font-lock-mode-check-buffers debugger-reenable))
* remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--returning value: (global-font-lock-mode-check-buffers)
  delete(debugger-reenable (global-font-lock-mode-check-buffers))
* remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--entering a function:
* set-default(post-command-hook (global-font-lock-mode-check-buffers))
* remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--returning value: (global-font-lock-mode-check-buffers)
  set-default(post-command-hook (global-font-lock-mode-check-buffers))
* remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--returning value: (global-font-lock-mode-check-buffers)
  remove-hook(post-command-hook debugger-reenable)
* debugger-reenable()

Debugger entered--returning value: (global-font-lock-mode-check-buffers)
  debugger-reenable()

Debugger entered--entering a function:
* #[128 "\300\301�\"\210\300\302�\"\207" [apply redisplay--update-region-highlights ignore nil] 4 nil nil](t)
  redisplay_internal\ \(C\ function\)()

Debugger entered--beginning evaluation of function call form:
* (normal-top-level)

veripoolbot · 2016-06-24T16:31:38Z

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2016-06-24T16:31:38Z

That debug-on-quit doesn't work, and that there are no calls to verilog-mode in the functions you indicate mean that the bug is in the Emacs internals. It might mean that some setup verilog-mode does is funky but it at least needs to be debugged there. Please file a bug as described here:

https://www.gnu.org/software/emacs/manual/html_node/emacs/Checklist.html#Checklist

veripoolbot · 2016-06-24T19:11:47Z

Original Redmine Comment
Author Name: Ian Perryman
Original Date: 2016-06-24T19:11:47Z

Done

I will update this bug when I get an acknowledgement.

veripoolbot · 2016-06-24T19:50:22Z

Original Redmine Comment
Author Name: Ian Perryman
Original Date: 2016-06-24T19:50:22Z

This issue is also being tracked as bug#23842: 24.4; Runaway background process at bug-gnu-emacs

http://lists.gnu.org/archive/html/bug-gnu-emacs/2016-06/msg01098.html

veripoolbot · 2016-06-27T14:18:36Z

Original Redmine Comment
Author Name: Ian Perryman
Original Date: 2016-06-27T14:18:36Z

Does this feature work for anyone?

I could not get it to work in emacs 23.1 or 24.1 or 24.4.

Which version of emacs was it developed it?

What is the intended behaviour?

Here is a response from an emacs developer who questions how the code in the function "verilog-show-completions" could ever work.

http://lists.gnu.org/archive/html/bug-gnu-emacs/2016-06/msg01229.html


Ken Brown <kbrown@cornell.edu>
9:24 AM (30 minutes ago)

to me, Paul, 23842 
On 6/27/2016 8:46 AM, Ian Perryman wrote:
I tried down grading to emacs 24.1.1 in windows to see if the problem
still exists.

The good news is that the process does not runaway to 100% CPU like with
emacs 24.4, but it still does not do the completion.  I get the "wrong
type argument: window-live-p, #<window 5>"

The window # would change as I tried it multiple times.

This appears to the be the same issue that is now reported in emacs 25.

The same error is given in emacs 23.1.1

Not sure when this worked.

I know virtually nothing about how completion works, but a glance at verilog-mode.el shows the following code, in both verilog-show-completions and verilog-complete-word:

     ;; Show possible completions in a temporary buffer.
     (with-output-to-temp-buffer "*Completions*"
       (display-completion-list allcomp))
     ;; Wait for a key press. Then delete *Completion*  window
     (momentary-string-display "" (point))
     (delete-window (get-buffer-window (get-buffer "*Completions*")))))

It's hard to see how this could possibly work.  As soon as you click in the *Completion* window, the window is deleted.  Here's a lisp backtrace:

Debugger entered--Lisp error: (wrong-type-argument window-live-p #<window 6>)
  get-char-property(129 follow-link #<window 6>)
  mouse-posn-property((#<window 6> 129 (35 . 76) 415716125 nil 129 (3 . 4) nil (8 . 4) (9 . 18)) follow-link)
  mouse-on-link-p((#<window 6> 129 (35 . 76) 415716125 nil 129 (3 . 4) nil (8 . 4) (9 . 18)))
  mouse--down-1-maybe-follows-link(nil)

The error is generated when Fget_char_property (in textprop.c) calls get_char_property_and_overlay, which calls CHECK_LIVE_WINDOW on a window that has already been deleted.

veripoolbot · 2016-07-09T18:21:58Z

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2016-07-09T18:21:58Z

Looking at the git history, this code was designed for Emacs 19. Given the error this must be pretty infrequently used. If you'd be willing to give it some love to clean it up, it would be appreciated.

veripoolbot · 2016-07-11T14:43:21Z

Original Redmine Comment
Author Name: Ian Perryman
Original Date: 2016-07-11T14:43:21Z

Hi Wilson,

I will see what I can do.

First I have to figure out what the right paradigm is now handling a completion buffer in recent emacsen.

I think the problem in the current code is that the call to momentary-string-display behaves differently now than it did in emacs 19.

Do you suggest that the feature be made conditional?

Ie. check the version of emacs in use and use old behaviour for Emacs 19. Not sure when the behaviour started failing.

I know it does not work in emacs 23 or 24. Not sure about 20, 21, 22.

Not sure how retro you want to maintain the code.

Ian

veripoolbot · 2016-07-14T02:48:41Z

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2016-07-14T02:48:41Z

We generally try to keep as many versions as possible, but I think think in this case Emacs 23 is a fine lowest bar.

veripoolbot · 2017-11-19T14:00:11Z

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2017-11-19T14:00:11Z

AFAIK this is still an issue.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Auto-completion results in runaway emacs process in emacs 24.4 on Debian using 2016-04-23-5f6855e-vpo #1070

Auto-completion results in runaway emacs process in emacs 24.4 on Debian using 2016-04-23-5f6855e-vpo #1070

veripoolbot commented Jun 23, 2016

veripoolbot commented Jun 23, 2016

veripoolbot commented Jun 24, 2016

veripoolbot commented Jun 24, 2016

veripoolbot commented Jun 24, 2016

veripoolbot commented Jun 24, 2016

veripoolbot commented Jun 24, 2016

veripoolbot commented Jun 24, 2016

veripoolbot commented Jun 24, 2016

veripoolbot commented Jun 27, 2016

veripoolbot commented Jul 9, 2016

veripoolbot commented Jul 11, 2016

veripoolbot commented Jul 14, 2016

veripoolbot commented Nov 19, 2017

Auto-completion results in runaway emacs process in emacs 24.4 on Debian using 2016-04-23-5f6855e-vpo #1070

Auto-completion results in runaway emacs process in emacs 24.4 on Debian using 2016-04-23-5f6855e-vpo #1070

Comments

veripoolbot commented Jun 23, 2016

veripoolbot commented Jun 23, 2016

veripoolbot commented Jun 24, 2016

veripoolbot commented Jun 24, 2016

veripoolbot commented Jun 24, 2016

veripoolbot commented Jun 24, 2016

veripoolbot commented Jun 24, 2016

veripoolbot commented Jun 24, 2016

veripoolbot commented Jun 24, 2016

veripoolbot commented Jun 27, 2016

veripoolbot commented Jul 9, 2016

veripoolbot commented Jul 11, 2016

veripoolbot commented Jul 14, 2016

veripoolbot commented Nov 19, 2017