From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ian Perryman Newsgroups: gmane.emacs.bugs Subject: bug#23842: 24.4; Runaway background process Date: Mon, 27 Jun 2016 09:51:47 -0400 Message-ID: References: <576F977E.8060405@cs.ucla.edu> <57703204.9090402@cs.ucla.edu> <02ecaa18-2108-e5c7-c7c4-56896a9c2869@cornell.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114f05f0580379053642d260 X-Trace: ger.gmane.org 1467035556 3082 80.91.229.3 (27 Jun 2016 13:52:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jun 2016 13:52:36 +0000 (UTC) Cc: Paul Eggert , 23842@debbugs.gnu.org To: Ken Brown Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 27 15:52:27 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bHWxe-0007iY-KD for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Jun 2016 15:52:26 +0200 Original-Received: from localhost ([::1]:58847 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHWxV-00005P-OR for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Jun 2016 09:52:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHWxK-0008Sl-DP for bug-gnu-emacs@gnu.org; Mon, 27 Jun 2016 09:52:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHWxG-0002R4-68 for bug-gnu-emacs@gnu.org; Mon, 27 Jun 2016 09:52:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45242) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHWxG-0002R0-11 for bug-gnu-emacs@gnu.org; Mon, 27 Jun 2016 09:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bHWxF-0002dZ-MQ for bug-gnu-emacs@gnu.org; Mon, 27 Jun 2016 09:52:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ian Perryman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Jun 2016 13:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23842 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23842-submit@debbugs.gnu.org id=B23842.146703551610123 (code B ref 23842); Mon, 27 Jun 2016 13:52:01 +0000 Original-Received: (at 23842) by debbugs.gnu.org; 27 Jun 2016 13:51:56 +0000 Original-Received: from localhost ([127.0.0.1]:57579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bHWx9-0002dB-Fm for submit@debbugs.gnu.org; Mon, 27 Jun 2016 09:51:55 -0400 Original-Received: from mail-qk0-f179.google.com ([209.85.220.179]:36349) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bHWx8-0002cx-4T for 23842@debbugs.gnu.org; Mon, 27 Jun 2016 09:51:54 -0400 Original-Received: by mail-qk0-f179.google.com with SMTP id p10so205573485qke.3 for <23842@debbugs.gnu.org>; Mon, 27 Jun 2016 06:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xtreme-eda-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y+wy2TrCQka6P3+8xDnmtZJSmUn4QQI09ffY+8y0o+w=; b=hSUbDNXhla6sXw6VWJmh+5nVvukHZ29TSBz9ccQ2Odo276WcgKkz3JXfJ2/IV/EsHA VlcLn5Gs6AIiBdJ/K6HCCiLBvEQ+DK7F3maDvp/o1emdXX2Ri23OTritayZDv2PUYRZU X8jxwz0fPr09lMxuFeZ/EWT5wUbSmgf9ETHpT03wJtqesxpc0GapTu5plXj8Hg7d/pDy H6jkp20QLMKspzl2c/vg6AKiQVggoMYLH6+HZpsTbixekqfZgNWkyiqdo5e7zJceX2E9 LNXnBqd6Ak3d5cziN+Pc7lAtLcTqui8Gjt4go35CEcN/iYEL8/1H0YPFHHmSs0AvbA3i 8fBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y+wy2TrCQka6P3+8xDnmtZJSmUn4QQI09ffY+8y0o+w=; b=W6qAauh7Iw1DW/E6iicvnjW6w5yIOQndPTkCOsGa3/o71ui/D8Y+cPQ6NxfTamJ6JU /u/nyfis76xYBsrahY2x1Vu86wmtCbNJ20Y0ahQxJRf+bwnAd93bmq5z7BeSRL34UW+d NLdMPAijoZ7ZVAjGoEGp1gw6ijWuUTD5m3IpCPysaWPgselWEdGsasveoqs0ogWpAY3q AFF4DA1k9rhLCFWGX+Bu6dHPtjvUvSduw9QAg8ycQbub57qomrCWAzTsqUXfdVEuQ0x4 1IplpYa/q8c+PR41UAKJbzwekDW4jHrzeAPhH2VQScQhYkUaCgadTNUevOwkoLl6aYwV 9/uQ== X-Gm-Message-State: ALyK8tKH7m6WXw0b6nxSMPb8JmxtmNrliOot+7qaGRdbasVfTUCabmeAygltj2X/VmBG7HYRNbQfRxDE8Cr1HfoH X-Received: by 10.129.136.129 with SMTP id y123mr11930443ywf.77.1467035508264; Mon, 27 Jun 2016 06:51:48 -0700 (PDT) Original-Received: by 10.129.155.8 with HTTP; Mon, 27 Jun 2016 06:51:47 -0700 (PDT) In-Reply-To: <02ecaa18-2108-e5c7-c7c4-56896a9c2869@cornell.edu> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:120148 Archived-At: --001a114f05f0580379053642d260 Content-Type: text/plain; charset=UTF-8 I am not the author of the verilog mode. I have alerted the maintainer to the issue at http://www.veripool.org/issues/1070-Verilog-mode-Auto-completion-results-in-runaway-emacs-process-in-emacs-24-4-on-Debian-using-2016-04-23-5f6855e-vpo Not sure what the intended behaviour is. My guess is that the list of possible completions was to be presented in the temporary buffer, and then user could select the completion they wanted with a mouse click and it should be inserted back in the original buffer. Did the definition of with-output-to-temp-buffer change over the years? I am not certain when this code was developed, but it was quite a while back. I am surprised that no one else has complained about it. Perhaps the paradigm for completion is not being followed by this mode? Any suggestions? Ian On Mon, Jun 27, 2016 at 9:24 AM, Ken Brown wrote: > 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, #" >> >> 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 # 6>) > get-char-property(129 follow-link #) > mouse-posn-property((# 129 (35 . 76) 415716125 nil 129 (3 . 4) > nil (8 . 4) (9 . 18)) follow-link) > mouse-on-link-p((# 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. > > Ken > --001a114f05f0580379053642d260 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am not the author of the verilog mode.=C2=A0 I have aler= ted the maintainer to the issue at=C2=A0http://www.veripool.or= g/issues/1070-Verilog-mode-Auto-completion-results-in-runaway-emacs-process= -in-emacs-24-4-on-Debian-using-2016-04-23-5f6855e-vpo

Not sure what the intended behaviour is.=C2=A0 My guess is that the list = of possible completions was to be presented in the temporary buffer, and th= en =C2=A0user could select the completion they wanted with a mouse click an= d it should be inserted back in the original buffer. =C2=A0

<= /div>
Did the definition of with-output-to-temp-buffer change over the = years?=C2=A0 I am not certain when this code was developed, but it was quit= e a while back.=C2=A0 I am surprised that no one else has complained about = it.

Perhaps the paradigm for completion is not bei= ng followed by this mode?

Any suggestions?

Ian

On Mon, Jun 27, 2016 at 9:24 AM, Ken Brown <kbrown@corne= ll.edu> wrote:
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.=C2=A0 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 verilo= g-mode.el shows the following code, in both verilog-show-completions and ve= rilog-complete-word:

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

It's hard to see how this could possibly work.=C2=A0 As soon as you cli= ck in the *Completion* window, the window is deleted.=C2=A0 Here's a li= sp backtrace:

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

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

Ken

--001a114f05f0580379053642d260--