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

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

[Francesco Potortì]

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\x03#\207 [apply smie-auto-fill #[128 \301\302\300!\x02"\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))

bug#27036: Acknowledgement (25.1; Blocking call to accept-process-output with quit inhibited!!)

[Francesco Potortì]

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.

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

[Dmitry Gutov]

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.

bug#27036: Acknowledgement (25.1; Blocking call to accept-process-output with quit inhibited!!)

[Francesco Potortì]

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.

bug#27036: Acknowledgement (25.1; Blocking call to accept-process-output with quit inhibited!!)

[Eli Zaretskii]

> Date: Wed, 24 May 2017 16:27:49 +0200
> From: Francesco Potortì <pot@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.

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@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.

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

[Dmitry Gutov]

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.

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

[Eli Zaretskii]

> Cc: pot@gnu.org, 27036@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@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.

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

[Dmitry Gutov]

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@entry=0, 
do_display=do_display@entry=false, 
wait_for_cell=wait_for_cell@entry=XIL(0),
     wait_proc=wait_proc@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.

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

[Noam Postavsky]

On Thu, May 25, 2017 at 8:43 AM, Dmitry Gutov <dgutov@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))

bug#27036: Acknowledgement (25.1; Blocking call to accept-process-output with quit inhibited!!)

[Francesco Potortì]

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.

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

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Thu, 25 May 2017 08:51:56 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, 27036@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?

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

[Dmitry Gutov]

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.

bug#27036: Acknowledgement (25.1; Blocking call to accept-process-output with quit inhibited!!)

[Dmitry Gutov]

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.

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

[Dmitry Gutov]

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))))

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

[Eli Zaretskii]

> Cc: 27036@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@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.

bug#27036: Acknowledgement (25.1; Blocking call to accept-process-output with quit inhibited!!)

[Francesco Potortì]

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.

bug#27036: Acknowledgement (25.1; Blocking call to accept-process-output with quit inhibited!!)

[Dmitry Gutov]

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

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).

[-- Attachment #2: octave-eldoc.diff --]
[-- Type: text/x-patch, Size: 2378 bytes --]

diff --git a/lisp/progmodes/octave.el b/lisp/progmodes/octave.el
index ac9ba63..d0a92d8 100644
--- a/lisp/progmodes/octave.el
+++ b/lisp/progmodes/octave.el
@@ -938,12 +938,19 @@ inferior-octave-send-list-and-digest
 	(while (setq string (car list))
 	  (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))
+	  (process-send-string proc string)
+	  (while
+              (and inferior-octave-receive-in-progress
+                   (with-local-quit
+                     (accept-process-output proc))))
 	  (setq list (cdr list)))
       (set-process-filter proc filter))))
 
+(defun inferior-octave--busy-p ()
+  (not
+   (buffer-local-value 'comint-last-prompt
+                       (process-buffer inferior-octave-process))))
+
 (defvar inferior-octave-directory-tracker-resync nil)
 (make-variable-buffer-local 'inferior-octave-directory-tracker-resync)
 
@@ -1586,19 +1593,21 @@ octave-eldoc-message-style
 (defvar octave-eldoc-cache nil)
 
 (defun octave-eldoc-function-signatures (fn)
-  (unless (equal fn (car octave-eldoc-cache))
-    (inferior-octave-send-list-and-digest
-     (list (format "print_usage ('%s');\n" fn)))
-    (let (result)
-      (dolist (line inferior-octave-output-list)
-        (when (string-match
-               "\\s-*\\(?:--[^:]+\\|usage\\):\\s-*\\(.*\\)$"
-               line)
-          (push (match-string 1 line) result)))
-      (setq octave-eldoc-cache
-            (cons (substring-no-properties fn)
-                  (nreverse result)))))
-  (cdr octave-eldoc-cache))
+  (if (equal fn (car octave-eldoc-cache))
+      (cdr octave-eldoc-cache)
+    (unless (inferior-octave--busy-p)
+      (inferior-octave-send-list-and-digest
+       (list (format "print_usage ('%s');\n" fn)))
+      (let (result)
+        (dolist (line inferior-octave-output-list)
+          (when (string-match
+                 "\\s-*\\(?:--[^:]+\\|usage\\):\\s-*\\(.*\\)$"
+                 line)
+            (push (match-string 1 line) result)))
+        (setq octave-eldoc-cache
+              (cons (substring-no-properties fn)
+                    (nreverse result))))
+      (cdr octave-eldoc-cache))))
 
 (defun octave-eldoc-function ()
   "A function for `eldoc-documentation-function' (which see)."

bug#27036: Acknowledgement (25.1; Blocking call to accept-process-output with quit inhibited!!)

[Francesco Potortì]

>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?

bug#27036: Acknowledgement (25.1; Blocking call to accept-process-output with quit inhibited!!)

[Dmitry Gutov]

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.

bug#27036: Acknowledgement (25.1; Blocking call to accept-process-output with quit inhibited!!)

[Dmitry Gutov]

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.

bug#27036: Acknowledgement (25.1; Blocking call to accept-process-output with quit inhibited!!)

[Francesco Potortì]

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

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

[Lars Ingebrigtsen]

Francesco Potortì <pot@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