GNU bug report logs - #27036
25.1; Blocking call to accept-process-output with quit inhibited!!

Previous Next

To reply to this bug, email your comments to 27036 AT debbugs.gnu.org.

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

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

From: Francesco Potortì <pot <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1; Blocking call to accept-process-output with quit inhibited!!
Date: Tue, 23 May 2017 14:20:07 +0200

I use inferior-octave-mode, where the Octave interpreter runs in a
buffer, similarly to shell-mode.

Starting somewhere later than Emacs 22, this mode makes on-the-fly
syntax suggestions whenever point is at a function definition or
similar.

Apparently something goes wrong with this funcitonality, or so I
suspect.  I get error messages about

  Blocking call to accept-process-output with quit inhibited!!

and even when this does not happen, Emacs sometimes freezes for a couple
of seconds especially when an inferior-octave buffer is visible.


In GNU Emacs 25.1.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2017-04-23, modified by Debian built on trouble
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
System Description:	Debian GNU/Linux 9.0 (stretch)

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --with-x=yes --with-x-toolkit=lucid
 --with-toolkit-scroll-bars --without-gconf --without-gsettings
 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs25-d2FC1K/emacs25-25.1+1=. -fstack-protector-strong
 -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS NOTIFY ACL
LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS LUCID X11

Important settings:
  value of $LC_COLLATE: it_IT.UTF-8
  value of $LC_CTYPE: it_IT.UTF-8
  value of $LC_NUMERIC: C
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Octave

Minor modes in effect:
  TeX-PDF-mode: t
  desktop-save-mode: t
  epa-global-mail-mode: t
  shell-dirtrack-mode: t
  openwith-mode: t
  xterm-mouse-mode: t
  display-time-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-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
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: #[128 \300\301\302#\207 [apply smie-auto-fill #[128 \301\302\300!"\207 [normal-auto-fill-function apply default-value] 4 

(fn &rest ARGS)] nil] 5 nil]
  abbrev-mode: t

Recent messages:
Showing message 774...done
Showing message 774...done
Showing message 775...done
No following nondeleted message
Expunging deleted messages...done
Showing message 773...
Blocking call to accept-process-output with quit inhibited!!
Mark set
kill-region: Buffer is read-only: #<buffer *Messages*>
Making completion list...

Load-path shadows:
~/elisp/bhl hides /usr/share/emacs/25.1/site-lisp/bhl
~/elisp/bhl hides /usr/share/emacs/site-lisp/bhl
/usr/share/emacs/25.1/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs25/site-lisp/flim/md4 hides /usr/share/emacs/25.1/lisp/md4
/usr/share/emacs25/site-lisp/flim/hex-util hides /usr/share/emacs/25.1/lisp/hex-util
/usr/share/emacs/site-lisp/rst hides /usr/share/emacs/25.1/lisp/textmodes/rst
~/elisp/bibtex hides /usr/share/emacs/25.1/lisp/textmodes/bibtex
/usr/share/emacs25/site-lisp/flim/ntlm hides /usr/share/emacs/25.1/lisp/net/ntlm
/usr/share/emacs25/site-lisp/flim/hmac-md5 hides /usr/share/emacs/25.1/lisp/net/hmac-md5
/usr/share/emacs25/site-lisp/flim/sasl-ntlm hides /usr/share/emacs/25.1/lisp/net/sasl-ntlm
/usr/share/emacs25/site-lisp/flim/sasl-digest hides /usr/share/emacs/25.1/lisp/net/sasl-digest
/usr/share/emacs25/site-lisp/flim/sasl hides /usr/share/emacs/25.1/lisp/net/sasl
/usr/share/emacs25/site-lisp/flim/sasl-cram hides /usr/share/emacs/25.1/lisp/net/sasl-cram
/usr/share/emacs25/site-lisp/flim/hmac-def hides /usr/share/emacs/25.1/lisp/net/hmac-def
/usr/share/emacs25/site-lisp/auctex/tex-fold hides /usr/share/emacs/site-lisp/auctex/tex-fold
/usr/share/emacs25/site-lisp/auctex/context-en hides /usr/share/emacs/site-lisp/auctex/context-en
/usr/share/emacs25/site-lisp/auctex/tex-info hides /usr/share/emacs/site-lisp/auctex/tex-info
/usr/share/emacs25/site-lisp/auctex/plain-tex hides /usr/share/emacs/site-lisp/auctex/plain-tex
/usr/share/emacs25/site-lisp/auctex/tex-mik hides /usr/share/emacs/site-lisp/auctex/tex-mik
/usr/share/emacs25/site-lisp/auctex/texmathp hides /usr/share/emacs/site-lisp/auctex/texmathp
/usr/share/emacs25/site-lisp/auctex/context-nl hides /usr/share/emacs/site-lisp/auctex/context-nl
/usr/share/emacs25/site-lisp/auctex/toolbar-x hides /usr/share/emacs/site-lisp/auctex/toolbar-x
/usr/share/emacs25/site-lisp/auctex/tex hides /usr/share/emacs/site-lisp/auctex/tex
/usr/share/emacs25/site-lisp/auctex/tex-jp hides /usr/share/emacs/site-lisp/auctex/tex-jp
/usr/share/emacs25/site-lisp/auctex/tex-ispell hides /usr/share/emacs/site-lisp/auctex/tex-ispell
/usr/share/emacs25/site-lisp/auctex/bib-cite hides /usr/share/emacs/site-lisp/auctex/bib-cite
/usr/share/emacs25/site-lisp/auctex/multi-prompt hides /usr/share/emacs/site-lisp/auctex/multi-prompt
/usr/share/emacs25/site-lisp/auctex/font-latex hides /usr/share/emacs/site-lisp/auctex/font-latex
/usr/share/emacs25/site-lisp/auctex/prv-emacs hides /usr/share/emacs/site-lisp/auctex/prv-emacs
/usr/share/emacs25/site-lisp/auctex/tex-style hides /usr/share/emacs/site-lisp/auctex/tex-style
/usr/share/emacs25/site-lisp/auctex/context hides /usr/share/emacs/site-lisp/auctex/context
/usr/share/emacs25/site-lisp/auctex/preview hides /usr/share/emacs/site-lisp/auctex/preview
/usr/share/emacs25/site-lisp/auctex/tex-font hides /usr/share/emacs/site-lisp/auctex/tex-font
/usr/share/emacs25/site-lisp/auctex/tex-bar hides /usr/share/emacs/site-lisp/auctex/tex-bar
/usr/share/emacs25/site-lisp/auctex/latex hides /usr/share/emacs/site-lisp/auctex/latex
/usr/share/emacs25/site-lisp/auctex/tex-buf hides /usr/share/emacs/site-lisp/auctex/tex-buf

Features:
(shadow emacsbug nero url-handlers timezone rmailsort rmailkwd macros
rmailedit dabbrev face-remap url-util rmailout shr-color color
time-stamp mailalias misearch multi-isearch server jka-compr bibtex
sh-script executable generic image-mode vc-filewise vc-rcs js json map
imenu info sgml-mode octave smie cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs latexenc preview
prv-emacs noutline outline vc-dispatcher vc-svn tex-bar toolbar-x
font-latex plain-tex tex-buf latex easy-mmode edmacro kmacro tex-ispell
tex-style tex dbus xml crm tex-mode compile qp shr dom subr-x browse-url
rmailmm message rfc822 mml mml-sec mm-decode mm-bodies mm-encode
mailabbrev gmm-utils mailheader mail-parse rfc2231 desktop frameset
solar cal-dst pot skeleton warnings rmailsum rmail sendmail rfc2047
rfc2045 ietf-drums mime-compose epa-mail mail-utils epa derived epg view
holidays hol-loaddefs appt diary-lib diary-loaddefs cal-menu calendar
cal-loaddefs tramp tramp-compat tramp-loaddefs trampver ucs-normalize
shell pcomplete comint ring format-spec advice bhl visual-fill-column
switch-to-shell openwith hi-lock xt-mouse ffap thingatpt url-parse
auth-source cl-seq eieio eieio-core cl-macs gnus-util time-date mm-util
help-fns mail-prsvr password-cache url-vars scroll-in-place filladapt
ansi-color time quail dired-x dired generic-x disp-table finder-inf
package epg-config seq byte-opt gv bytecomp byte-compile cl-extra
help-mode easymenu cconv cl-loaddefs pcase cl-lib debian-el
debian-el-loaddefs w3m-load vm-autoload vm-autoloads vm-version vm-vars
vm-init preview-latex tex-site auto-loads mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core 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 charscript case-table epa-hook jka-cmpr-hook help
simple abbrev 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
dbusbind inotify dynamic-setting font-render-setting x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 501140 83314)
 (symbols 48 38883 0)
 (miscs 40 4472 3099)
 (strings 32 88491 12631)
 (string-bytes 1 2960232)
 (vectors 16 61969)
 (vector-slots 8 1796414 229655)
 (floats 8 855 922)
 (intervals 56 22145 326)
 (buffers 976 118))

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

From: Francesco Potortì <pot <at> gnu.org>
To: 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: Acknowledgement (25.1; Blocking call to
 accept-process-output with quit inhibited!!)
Date: Wed, 24 May 2017 13:21:11 +0200

I had Emacs dump core on me in connection with this problem.

This happened when I had two buffers open in two windows: an
inferior-octave-mode buffer and a source code buffer in octave-mode.

While Octave was busy doing some computation in the inferior-octave-mode
buffer, after moving point on the source code buffer to a standard
function call, I got the infamous message in the subject.

At this point, Emacs refused to answer.  After some C-g, it offered to
auto-save and then dump core, which I did.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Francesco Potortì <pot <at> gnu.org>, 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: 25.1; Blocking call to accept-process-output with quit
 inhibited!!
Date: Wed, 24 May 2017 15:24:17 +0300

On 5/23/17 3:20 PM, Francesco Potortì wrote:
> I use inferior-octave-mode, where the Octave interpreter runs in a
> buffer, similarly to shell-mode.
> 
> Starting somewhere later than Emacs 22, this mode makes on-the-fly
> syntax suggestions whenever point is at a function definition or
> similar.
> 
> Apparently something goes wrong with this funcitonality, or so I
> suspect.  I get error messages about
> 
>    Blocking call to accept-process-output with quit inhibited!!

I can see it here.

It's pretty weird, though. Neither octave.el not comint.el reference 
inhibit-quit.

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

From: Francesco Potortì <pot <at> gnu.org>
To: 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: Acknowledgement (25.1; Blocking call to
 accept-process-output with quit inhibited!!)
Date: Wed, 24 May 2017 16:27:49 +0200

I had Emacs dump core on me in connection with this problem.

This happened when I had two buffers open in two windows: an
inferior-octave-mode buffer and a source code buffer in octave-mode.

While Octave was busy doing some computation in the inferior-octave-mode
buffer, after moving point on the source code buffer to a standard
function call, I got the infamous message in the subject.

At this point, Emacs refused to answer.  After some C-g, it offered to
auto-save and then dump core, which I did.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Francesco Potortì <pot <at> gnu.org>
Cc: 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: Acknowledgement (25.1;
 Blocking call to accept-process-output with quit inhibited!!)
Date: Wed, 24 May 2017 20:57:26 +0300

> Date: Wed, 24 May 2017 16:27:49 +0200
> From: Francesco Potortì <pot <at> gnu.org>
> 
> I had Emacs dump core on me in connection with this problem.
> 
> This happened when I had two buffers open in two windows: an
> inferior-octave-mode buffer and a source code buffer in octave-mode.
> 
> While Octave was busy doing some computation in the inferior-octave-mode
> buffer, after moving point on the source code buffer to a standard
> function call, I got the infamous message in the subject.
> 
> At this point, Emacs refused to answer.  After some C-g, it offered to
> auto-save and then dump core, which I did.

When these things happen, please in the future attach a debugger and
try producing a backtrace, that could allow us to try to figure out
what was the reason of the problem.  Unless you can reproduce the
problem at will, of course.

Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: pot <at> gnu.org, 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: 25.1;
 Blocking call to accept-process-output with quit inhibited!!
Date: Wed, 24 May 2017 21:01:14 +0300

> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Wed, 24 May 2017 15:24:17 +0300
> 
> On 5/23/17 3:20 PM, Francesco Potortì wrote:
> > I use inferior-octave-mode, where the Octave interpreter runs in a
> > buffer, similarly to shell-mode.
> > 
> > Starting somewhere later than Emacs 22, this mode makes on-the-fly
> > syntax suggestions whenever point is at a function definition or
> > similar.
> > 
> > Apparently something goes wrong with this funcitonality, or so I
> > suspect.  I get error messages about
> > 
> >    Blocking call to accept-process-output with quit inhibited!!
> 
> I can see it here.

"See" meaning you can reproduce the hang?

> It's pretty weird, though. Neither octave.el not comint.el reference 
> inhibit-quit.

According to description, Francesco was editing while
inferior-octave-mode was doing something in the background, so it's
possible that some foreground code just happened to bind inhibit-quit
at the wrong moment.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pot <at> gnu.org, 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: 25.1; Blocking call to accept-process-output with quit
 inhibited!!
Date: Wed, 24 May 2017 21:17:15 +0300

On 5/24/17 9:01 PM, Eli Zaretskii wrote:

>>>     Blocking call to accept-process-output with quit inhibited!!
>>
>> I can see it here.
> 
> "See" meaning you can reproduce the hang?

Yes:

1. Install Octave.
2. emacs -Q
3. M-x run-octave
4. Switch to octave-mode in the scratch, delete everything.
5. Type 'abs ', wait. See that message.

I don't see any freezing, though.

Only see this message once (repeated twice, though) in an 'emacs -Q' 
session, but in my normal session I can repeat it at will by deleting 's 
' and typing them again.

>> It's pretty weird, though. Neither octave.el not comint.el reference
>> inhibit-quit.
> 
> According to description, Francesco was editing while
> inferior-octave-mode was doing something in the background, so it's
> possible that some foreground code just happened to bind inhibit-quit
> at the wrong moment.

Indeed, but what foreground code? The major mode is octave-mode.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: pot <at> gnu.org, 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: 25.1; Blocking call to accept-process-output with quit
 inhibited!!
Date: Wed, 24 May 2017 22:05:51 +0300

> Cc: pot <at> gnu.org, 27036 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Wed, 24 May 2017 21:17:15 +0300
> 
> I don't see any freezing, though.

That's good.

> >> It's pretty weird, though. Neither octave.el not comint.el reference
> >> inhibit-quit.
> > 
> > According to description, Francesco was editing while
> > inferior-octave-mode was doing something in the background, so it's
> > possible that some foreground code just happened to bind inhibit-quit
> > at the wrong moment.
> 
> Indeed, but what foreground code? The major mode is octave-mode.

If you can reproduce this at will, run under GDB, put a breakpoint at
the line which emits the message, and when it breaks, produce a
backtrace.  I'd expect the offending code to be evident from that,
especially if you also run "xbacktrace" to see the Lisp backtrace.

Thanks.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: 25.1; Blocking call to accept-process-output with quit
 inhibited!!
Date: Thu, 25 May 2017 15:43:14 +0300

On 5/24/17 10:05 PM, Eli Zaretskii wrote:

> If you can reproduce this at will, run under GDB, put a breakpoint at
> the line which emits the message, and when it breaks, produce a
> backtrace.  I'd expect the offending code to be evident from that,
> especially if you also run "xbacktrace" to see the Lisp backtrace.

Here it is:

Thread 1 "emacs" hit Breakpoint 3, wait_reading_process_output 
(time_limit=0, nsecs=0, read_kbd=read_kbd <at> entry=0, 
do_display=do_display <at> entry=false, 
wait_for_cell=wait_for_cell <at> entry=XIL(0),
    wait_proc=wait_proc <at> entry=0x1399c30 <bss_sbrk_buffer+7942096>, 
just_wait_proc=0) at process.c:5015
5015	    message1 ("Blocking call to accept-process-output with quit 
inhibited!!");
(gdb) xbacktrace
"accept-process-output" (0xffffb980)
"inferior-octave-send-list-and-digest" (0xffffbc78)
"octave-eldoc-function-signatures" (0xffffbf68)
"octave-eldoc-function" (0xffffc410)
"apply" (0xffffc408)
0x13fef90 PVEC_COMPILED
"eldoc-print-current-symbol-info" (0xffffc950)
0xa3dc38 PVEC_COMPILED
"apply" (0xffffcd58)
"timer-event-handler" (0xffffd0a8)

Any ideas?

eldoc-print-current-symbol-info uses with-demoted-errors, which expands 
into a condition-case, but does that inhibit quitting somehow?

And inferior-octave-send-list-and-digest uses unwind-protect.

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: 25.1;
 Blocking call to accept-process-output with quit inhibited!!
Date: Thu, 25 May 2017 08:51:56 -0400

On Thu, May 25, 2017 at 8:43 AM, Dmitry Gutov <dgutov <at> yandex.ru> wrote:

> (gdb) xbacktrace
> "accept-process-output" (0xffffb980)
> "inferior-octave-send-list-and-digest" (0xffffbc78)
> "octave-eldoc-function-signatures" (0xffffbf68)
> "octave-eldoc-function" (0xffffc410)
> "apply" (0xffffc408)
> 0x13fef90 PVEC_COMPILED
> "eldoc-print-current-symbol-info" (0xffffc950)
> 0xa3dc38 PVEC_COMPILED
> "apply" (0xffffcd58)
> "timer-event-handler" (0xffffd0a8)
>
> Any ideas?
>
> eldoc-print-current-symbol-info uses with-demoted-errors, which expands into
> a condition-case, but does that inhibit quitting somehow?

Looks like it's in timer-event-handler:

(defun timer-event-handler (timer)
  ...
  (let ((inhibit-quit t))

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

From: Francesco Potortì <pot <at> gnu.org>
To: 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: Acknowledgement (25.1; Blocking call to
 accept-process-output with quit inhibited!!)
Date: Thu, 25 May 2017 17:58:10 +0200

Some more info.  In an octave-mode buffer (when you find Octave source
code), in the Octave menu, I find a switch for Function Syntax Hints.

However, hints are always provided, whether the switch is on or off.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 27036 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#27036: 25.1;
 Blocking call to accept-process-output with quit inhibited!!
Date: Thu, 25 May 2017 19:14:55 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Thu, 25 May 2017 08:51:56 -0400
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 27036 <at> debbugs.gnu.org
> 
> > eldoc-print-current-symbol-info uses with-demoted-errors, which expands into
> > a condition-case, but does that inhibit quitting somehow?
> 
> Looks like it's in timer-event-handler:
> 
> (defun timer-event-handler (timer)
>   ...
>   (let ((inhibit-quit t))

So I guess octave-eldoc-function-signatures should temporarily reset
inhibit-quit?

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: 25.1; Blocking call to accept-process-output with quit
 inhibited!!
Date: Fri, 26 May 2017 03:38:09 +0300

On 5/25/17 3:51 PM, Noam Postavsky wrote:

> Looks like it's in timer-event-handler:
> 
> (defun timer-event-handler (timer)
>    ...
>    (let ((inhibit-quit t))

Oh. Thanks! Somehow I skipped over this also being implemented in Lisp.

So apparently timer functions are not allowed to signal quit.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Francesco Potortì <pot <at> gnu.org>, 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: Acknowledgement (25.1; Blocking call to
 accept-process-output with quit inhibited!!)
Date: Fri, 26 May 2017 03:41:36 +0300

On 5/25/17 6:58 PM, Francesco Potortì wrote:
> Some more info.  In an octave-mode buffer (when you find Octave source
> code), in the Octave menu, I find a switch for Function Syntax Hints.
> 
> However, hints are always provided, whether the switch is on or off.

This is https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19853, orthogonal 
to the currently discussed problem.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>,
 Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: 25.1; Blocking call to accept-process-output with quit
 inhibited!!
Date: Fri, 26 May 2017 04:02:34 +0300

On 5/25/17 7:14 PM, Eli Zaretskii wrote:

> So I guess octave-eldoc-function-signatures should temporarily reset
> inhibit-quit?

Yes. Or more concretely, use with-local-quit like 
url-retrieve-synchronously does.

In the context of comint, though, we might consider what to do if Octave 
actually takes too long to produce the result, the user presses C-g, and 
we need to abort. Do we restore the normal process filter, and refuse to 
be bothered even though Octave will continue producing output (now 
visible to the user if they switch to the REPL buffer)?

As a first approximation, this seems to fix the bug:

diff --git a/lisp/progmodes/octave.el b/lisp/progmodes/octave.el
index ac9ba63..ce3c27a 100644
--- a/lisp/progmodes/octave.el
+++ b/lisp/progmodes/octave.el
@@ -939,8 +939,10 @@ inferior-octave-send-list-and-digest
 	  (setq inferior-octave-output-string nil
 		inferior-octave-receive-in-progress t)
 	  (comint-send-string proc string)
-	  (while inferior-octave-receive-in-progress
-	    (accept-process-output proc))
+	  (while
+              (and inferior-octave-receive-in-progress
+                   (with-local-quit
+                     (accept-process-output proc))))
 	  (setq list (cdr list)))
       (set-process-filter proc filter))))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 27036 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#27036: 25.1; Blocking call to accept-process-output with quit
 inhibited!!
Date: Fri, 26 May 2017 09:07:24 +0300

> Cc: 27036 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 26 May 2017 04:02:34 +0300
> 
> As a first approximation, this seems to fix the bug:

Thanks.  If no one objects in a few days, please push.

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

From: Francesco Potortì <pot <at> gnu.org>
To: 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: Acknowledgement (25.1; Blocking call to
 accept-process-output with quit inhibited!!)
Date: Fri, 26 May 2017 15:17:23 +0200

I disabled the hints with
 M-x global-eldoc-mode

Now Emacs is more responsive when I edit an Octave source file and use
the inferior Octave buffer.

I suspect that, when moving point in the source code and even in the
running Octave window, as soon as eldoc mode sees a function near point
it secretely sends a help command to the inferior Octave: the same
inferior Octave which I am using.

This works mot of the time, but if Octave is running a long command it
locks Emacs until the long command execution finishes and the prompt is
returned.

It also makes damage in some other cases that I cannot identify.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Francesco Potortì <pot <at> gnu.org>, 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: Acknowledgement (25.1; Blocking call to
 accept-process-output with quit inhibited!!)
Date: Sat, 27 May 2017 03:22:19 +0300

[Message part 1 (text/plain, inline)]

On 5/26/17 4:17 PM, Francesco Potortì wrote:

> if Octave is running a long command it
> locks Emacs until the long command execution finishes and the prompt is
> returned.

Yes, this problem should be common for all modes that use the REPL for 
fetching information like this. E.g. python-eldoc-function.

Normally, we don't see long-running commands in the user REPL. Or don't 
expect the user to switch back to the source buffer and continue 
editing. Octave might be a significant exception in that regard.

Anyway, please try the attached combined patch and see if it fixes your 
problem.

> It also makes damage in some other cases that I cannot identify.

If you have company-mode installed and enabled, similar problem can 
occur (when completion is triggered automatically).

[octave-eldoc.diff (text/x-patch, attachment)]

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

From: Francesco Potortì <pot <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: Acknowledgement (25.1; Blocking call to
 accept-process-output with quit inhibited!!)
Date: Tue, 30 May 2017 09:46:03 +0200

>On 5/26/17 4:17 PM, Francesco Potortì wrote:
>> if Octave is running a long command it
>> locks Emacs until the long command execution finishes and the prompt is
>> returned.
>
>Yes, this problem should be common for all modes that use the REPL for 
>fetching information like this. E.g. python-eldoc-function.
>
>Normally, we don't see long-running commands in the user REPL. Or don't 
>expect the user to switch back to the source buffer and continue 
>editing. Octave might be a significant exception in that regard.
>
>Anyway, please try the attached combined patch and see if it fixes your 
>problem.

It does not seem to work, sorry.  I launch a long-running command in the
inferior octave buffer, then in another window I go and edit the octave
source.  After a while everything is frozen.  The long-running command
is stopped midway and a syntax error is signaled which involves the
function point was on in the source.

I did not restart emacs for testing, I just evaluated the patched
octave.el.  Is that alright?

Does it makes sense at all to use the same process for interaction and
for asking help?  Wouldn't it be simpler and more robust if a dedicated
octave process was started for eldoc?

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Francesco Potortì <pot <at> gnu.org>
Cc: 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: Acknowledgement (25.1; Blocking call to
 accept-process-output with quit inhibited!!)
Date: Wed, 31 May 2017 01:39:02 +0300

On 5/30/17 10:46 AM, Francesco Potortì wrote:

> It does not seem to work, sorry.  I launch a long-running command in the
> inferior octave buffer, then in another window I go and edit the octave
> source.  After a while everything is frozen. 

Did you start with 'emacs -Q'? Or do you have e.g. company-mode enabled?

> I did not restart emacs for testing, I just evaluated the patched
> octave.el.  Is that alright?

Probably.

> Does it makes sense at all to use the same process for interaction and
> for asking help?  Wouldn't it be simpler and more robust if a dedicated
> octave process was started for eldoc?

No simpler, no. It's certainly easier to leave starting the process up 
to the user. Especially when projects and user code are involved.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Francesco Potortì <pot <at> gnu.org>
Cc: 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: Acknowledgement (25.1; Blocking call to
 accept-process-output with quit inhibited!!)
Date: Fri, 29 Sep 2017 00:06:53 +0300

If there's anybody else seeing this problem, could they please try out 
the patch and continue this discussion?

The change makes sense to me, but I'd rather not push it without a 
user's confirmation.

On 5/31/17 1:39 AM, Dmitry Gutov wrote:
> On 5/30/17 10:46 AM, Francesco Potortì wrote:
> 
>> It does not seem to work, sorry.  I launch a long-running command in the
>> inferior octave buffer, then in another window I go and edit the octave
>> source.  After a while everything is frozen. 
> 
> Did you start with 'emacs -Q'? Or do you have e.g. company-mode enabled?
> 
>> I did not restart emacs for testing, I just evaluated the patched
>> octave.el.  Is that alright?
> 
> Probably.
> 
>> Does it makes sense at all to use the same process for interaction and
>> for asking help?  Wouldn't it be simpler and more robust if a dedicated
>> octave process was started for eldoc?
> 
> No simpler, no. It's certainly easier to leave starting the process up 
> to the user. Especially when projects and user code are involved.

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

From: Francesco Potortì <pot <at> potorti.it>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 27036 <at> debbugs.gnu.org
Subject: Re: bug#27036: Acknowledgement (25.1; Blocking call to
 accept-process-output with quit inhibited!!)
Date: Fri, 29 Sep 2017 09:03:33 +0200

Sorry, I have been away for some time.  I hope to try this again soon.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Francesco Potortì <pot <at> potorti.it>
Cc: 27036 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#27036: 25.1; Blocking call to accept-process-output with
 quit inhibited!!
Date: Sat, 23 Apr 2022 17:24:14 +0200

Francesco Potortì <pot <at> potorti.it> writes:

> Sorry, I have been away for some time.  I hope to try this again soon.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

This was four years ago -- were you able to try the patch (if, indeed,
this problem is still present in recent Emacs versions)?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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