Blocking call to accept-process-output with quit inhibited!! [11 times]

Blocking call to accept-process-output with quit inhibited!! [11 times]

[Lars Magne Ingebrigtsen]

In Emacs 24, I get this message the first time I enter a Gnus group.
What does it mean, and what can I do to make it go away?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Stefan Monnier]

> In Emacs 24, I get this message the first time I enter a Gnus group.
> What does it mean, and what can I do to make it go away?

It means just that: accept-process-output is called in a way that can
block (e.g. because some remote host doesn't respond) wit inhibit0quit
set to a non-nil value, which means that Emacs may end up frozen (with
no way to wake it up) for as long as the remote machine decides not
to answer.

IOW, maybe there should be a (with-local-quit ...) somewhere so that the
user can C-g out of such a state (or the call should have a timeout, or
inhibit-quit should not be set, ...).


        Stefan

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> It means just that: accept-process-output is called in a way that can
> block (e.g. because some remote host doesn't respond) wit inhibit0quit
> set to a non-nil value, which means that Emacs may end up frozen (with
> no way to wake it up) for as long as the remote machine decides not
> to answer.

But all calls to `accept-process-output' in Gnus is called with a
timeout parameter, so there's no way Emacs could totally lock up.  I
think.  (It's typically called with a 0.1s or 0.01s timeout.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[joakim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> In Emacs 24, I get this message the first time I enter a Gnus group.
>> What does it mean, and what can I do to make it go away?
>
> It means just that: accept-process-output is called in a way that can
> block (e.g. because some remote host doesn't respond) wit inhibit0quit
> set to a non-nil value, which means that Emacs may end up frozen (with
> no way to wake it up) for as long as the remote machine decides not
> to answer.
>
> IOW, maybe there should be a (with-local-quit ...) somewhere so that the
> user can C-g out of such a state (or the call should have a timeout, or
> inhibit-quit should not be set, ...).

I get bitten by this quite a lot, since I'm often on a flaky 3g
line. When the link goes down, and some Emacs socket is still up, Emacs
freezes. This is quite annoying.

I suppose that the hard blocking is there to prevent data loss or
whatever, but having to kill -9 Emacs results in worse dataloss.

>
>
>         Stefan

-- 
Joakim Verona

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Stefan Monnier]

>>> In Emacs 24, I get this message the first time I enter a Gnus group.
>>> What does it mean, and what can I do to make it go away?
>> It means just that: accept-process-output is called in a way that can
>> block (e.g. because some remote host doesn't respond) wit inhibit0quit
>> set to a non-nil value, which means that Emacs may end up frozen (with
>> no way to wake it up) for as long as the remote machine decides not
>> to answer.
>> IOW, maybe there should be a (with-local-quit ...) somewhere so that the
>> user can C-g out of such a state (or the call should have a timeout, or
>> inhibit-quit should not be set, ...).

> I get bitten by this quite a lot, since I'm often on a flaky 3g
> line. When the link goes down, and some Emacs socket is still up, Emacs
> freezes. This is quite annoying.

Emacs should not freeze in such a case.  IIUC most cases where this
happen are Elisp bugs (typically a missing with-local-quit or something
like that), tho there are a few cases where it's a problem at the
C level (IIRC, one such is during hostname lookup, but I don't know of
any such case once the TCP connection is established).

> I suppose that the hard blocking is there to prevent data loss or
> whatever, but having to kill -9 Emacs results in worse dataloss.

No, usually it's there because the Elisp coder is not aware of the risk
(e.g. he doesn't realize his code will be run with inhibit-quit set,
probably because he doesn't realize that this is set whenever we run
process filters, process sentinels, post-command-hook, jit-lock,
timers, and a handful other cases).


        Stefan

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[joakim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> In Emacs 24, I get this message the first time I enter a Gnus group.
>>>> What does it mean, and what can I do to make it go away?
>>> It means just that: accept-process-output is called in a way that can
>>> block (e.g. because some remote host doesn't respond) wit inhibit0quit
>>> set to a non-nil value, which means that Emacs may end up frozen (with
>>> no way to wake it up) for as long as the remote machine decides not
>>> to answer.
>>> IOW, maybe there should be a (with-local-quit ...) somewhere so that the
>>> user can C-g out of such a state (or the call should have a timeout, or
>>> inhibit-quit should not be set, ...).
>
>> I get bitten by this quite a lot, since I'm often on a flaky 3g
>> line. When the link goes down, and some Emacs socket is still up, Emacs
>> freezes. This is quite annoying.
>
> Emacs should not freeze in such a case.  IIUC most cases where this
> happen are Elisp bugs (typically a missing with-local-quit or something
> like that), tho there are a few cases where it's a problem at the
> C level (IIRC, one such is during hostname lookup, but I don't know of
> any such case once the TCP connection is established).

But why then is quit inhibited at all?

Anyway, the freeze is quite easily reproducible. (as have been described in some
old bug reports)

- start gnus, make sure you read some nntp groups so nntp sockets are
  open
- make your network interface go away somehow (disconnecting 3g or
  something, but simply ifconfiging away should also work)
- stare in horror as your emacs freezes

This particular problem happens to me so often I have written a
workaround script like this:

,----
| #/bin/sh
| `lsof -n|grep emacs|grep nntp|sed "s/.*TCP\ \\([^:]*\\):.*->\\([^:].*\\):.*/  export a=\\1 export b=\\2/"`
| echo $a $b
| ifconfig eth2:1 $a
| ifconfig eth2:2 $b
| echo press enter when emacs is alive
| read
| ifconfig eth2:1 down
| ifconfig eth2:2 down
`----

since the socket is left even though the interface is gone, the script
ifconfigs new interfaces with information gleaned from the hanging
socket. After a while Emacs will live again, and the interfaces can be
removed.

>> I suppose that the hard blocking is there to prevent data loss or
>> whatever, but having to kill -9 Emacs results in worse dataloss.
>
> No, usually it's there because the Elisp coder is not aware of the risk
> (e.g. he doesn't realize his code will be run with inhibit-quit set,
> probably because he doesn't realize that this is set whenever we run
> process filters, process sentinels, post-command-hook, jit-lock,
> timers, and a handful other cases).
>
>
>         Stefan

-- 
Joakim Verona

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Lars Magne Ingebrigtsen]

joakim@verona.se writes:

> - start gnus, make sure you read some nntp groups so nntp sockets are
>   open
> - make your network interface go away somehow (disconnecting 3g or
>   something, but simply ifconfiging away should also work)
> - stare in horror as your emacs freezes

Does Emacs freeze immediately, or does it freeze the next time you try
to access the NNTP server?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> IOW, maybe there should be a (with-local-quit ...) somewhere so that the
> user can C-g out of such a state (or the call should have a timeout, or
> inhibit-quit should not be set, ...).

Is there a way to get a backtrace instead of the warning?  By looking at
the code, I can't tell where the message comes from.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[joakim]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> joakim@verona.se writes:
>
>> - start gnus, make sure you read some nntp groups so nntp sockets are
>>   open
>> - make your network interface go away somehow (disconnecting 3g or
>>   something, but simply ifconfiging away should also work)
>> - stare in horror as your emacs freezes
>
> Does Emacs freeze immediately, or does it freeze the next time you try
> to access the NNTP server?

sorry, the recipy should look more like this:

- start gnus, make sure you read some nntp groups so nntp sockets are
  open
- make your network interface go away somehow (disconnecting 3g or
  something, but simply ifconfiging away should also work)
- press "g" in the gnus group buffer
- stare in horror as your emacs freezes

-- 
Joakim Verona

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Lars Magne Ingebrigtsen]

joakim@verona.se writes:

> sorry, the recipy should look more like this:
>
> - start gnus, make sure you read some nntp groups so nntp sockets are
>   open
> - make your network interface go away somehow (disconnecting 3g or
>   something, but simply ifconfiging away should also work)
> - press "g" in the gnus group buffer
> - stare in horror as your emacs freezes

Are you absolutely sure that it's the nntp connection that causes it?
It doesn't inhibit quit anywhere...

To test that, try doing the same, but instead of `g', eval the
following:

`(nntp-request-list "your.server.name")'

That shouldn't do any name lookups (which I've experienced hangs with)
or the like, but just try to use the open socket, which you should be
able to `C-g' out of.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Tom Tromey]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

[ emacs hanging ]
Stefan> (IIRC, one such is during hostname lookup, but I don't know of
Stefan> any such case once the TCP connection is established).

I've been bitten by this a number of times.

It seems to me that Emacs could either resolve names in a separate
thread (so the originating thread could handle other I/O and be
interruptable) or do the work in a subprocess.

Tom

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Stefan Monnier]

>> Emacs should not freeze in such a case.  IIUC most cases where this
>> happen are Elisp bugs (typically a missing with-local-quit or something
>> like that), tho there are a few cases where it's a problem at the
>> C level (IIRC, one such is during hostname lookup, but I don't know of
>> any such case once the TCP connection is established).

> But why then is quit inhibited at all?

Because these are run asynchronously, so in most cases the user has no
idea that code is being executed at that point.  So if she hits C-g it's
likely to be for other reasons than to interrupt the async code, so by
default Emacs runs the async code to completion first and then processes
the C-g (you wouldn't want a C-g meant to abort a command to result in
a half-font-locked display, would you?).  I.e. if you want to execute
code that may last for a significant amount of time from one of those
places, you need with-local-quit (and you may want to make sure the user
knows that such code is being run).


        Stefan

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Stefan Monnier]

> [ emacs hanging ]
Stefan> (IIRC, one such is during hostname lookup, but I don't know of
Stefan> any such case once the TCP connection is established).
> I've been bitten by this a number of times.
> It seems to me that Emacs could either resolve names in a separate
> thread (so the originating thread could handle other I/O and be
> interruptable) or do the work in a subprocess.

I'd tend to agree.  Patches welcome.  Maybe the concurrency extension
will resolve this problem eventually.


        Stefan

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Stefan Monnier]

>> IOW, maybe there should be a (with-local-quit ...) somewhere so that the
>> user can C-g out of such a state (or the call should have a timeout, or
>> inhibit-quit should not be set, ...).
> Is there a way to get a backtrace instead of the warning?  By looking at
> the code, I can't tell where the message comes from.

Grep for the string in the C code and replace the call to `message' by
a call to `error' (that's what I have in my local branch, but placing
an `error' there would introduce a backward incompatibility with which I'm
not completely comfortable),


        Stefan

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Grep for the string in the C code and replace the call to `message' by
> a call to `error' (that's what I have in my local branch, but placing
> an `error' there would introduce a backward incompatibility with which I'm
> not completely comfortable),

Well...  `error' is a Lisp function, so I can't really call it from
there?  If I call Fsignal instead, like:

    Fsignal (Fintern(build_string("error"), Vobarray),
	     build_string("Blocking call to accept-process-output with quit inhibited!!"));

I don't get a backtrace, and the process apparently stops working.             

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Well...  `error' is a Lisp function, so I can't really call it from
> there?

error is also a C function, see eval.c.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> Well...  `error' is a Lisp function, so I can't really call it from
>> there?
>
> error is also a C function, see eval.c.

Right.  I'm still not getting any backtraces, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Stefan Monnier]

>>> Well...  `error' is a Lisp function, so I can't really call it from
>>> there?
>> error is also a C function, see eval.c.
> Right.  I'm still not getting any backtraces, though.

Sometimes the debugger is disabled because we're in the middle of
a special situation (e.g. during redisplay).  So maybe that's
the problem.

You may want to place a C breakpoint on the `message' (aka `error') call
and use xbacktrace from GDB when you hit it.  It's not as
convenient, tho.


        Stefan

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> You may want to place a C breakpoint on the `message' (aka `error') call
> and use xbacktrace from GDB when you hit it.  It's not as
> convenient, tho.

Nope.

The extra weird thing is that I get the message only once per Emacs
session -- the first time I select an article in the first group in
Gnus.  I have a feeling that it's being triggered by async article
prefetch -- but only the first time that code is run.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Lars Magne Ingebrigtsen]

I think the following patch does what the warning is intended to do:

=== modified file 'src/ChangeLog'
*** src/ChangeLog	2010-09-16 02:11:13 +0000
--- src/ChangeLog	2010-09-17 00:34:41 +0000
***************
*** 1,3 ****
--- 1,8 ----
+ 2010-09-17  Lars Magne Ingebrigtsen  <larsi@gnus.org>
+ 
+ 	* process.c (wait_reading_process_output): Don't message about
+ 	accept-process-output unless the time limit really is zero.
+ 
  2010-09-14  Kenichi Handa  <handa@m17n.org>
  
  	* ftfont.c (ftfont_check_otf): Fix the case of checking just

=== modified file 'src/process.c'
*** src/process.c	2010-08-22 15:14:37 +0000
--- src/process.c	2010-09-17 00:33:19 +0000
***************
*** 4403,4409 ****
    FD_ZERO (&Connecting);
  #endif
  
!   if (time_limit == 0 && wait_proc && !NILP (Vinhibit_quit)
        && !(CONSP (wait_proc->status) && EQ (XCAR (wait_proc->status), Qexit)))
      message ("Blocking call to accept-process-output with quit inhibited!!");
  
--- 4403,4409 ----
    FD_ZERO (&Connecting);
  #endif
  
!   if (time_limit == 0 && microsecs == 0 && wait_proc && !NILP (Vinhibit_quit)
        && !(CONSP (wait_proc->status) && EQ (XCAR (wait_proc->status), Qexit)))
      message ("Blocking call to accept-process-output with quit inhibited!!");
  


-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Stefan Monnier]

> ***************
> *** 4403,4409 ****
>     FD_ZERO (&Connecting);
>   #endif
  
> !   if (time_limit == 0 && wait_proc && !NILP (Vinhibit_quit)
>         && !(CONSP (wait_proc->status) && EQ (XCAR (wait_proc->status), Qexit)))
>       message ("Blocking call to accept-process-output with quit inhibited!!");
  
> --- 4403,4409 ----
>     FD_ZERO (&Connecting);
>   #endif
  
> !   if (time_limit == 0 && microsecs == 0 && wait_proc && !NILP (Vinhibit_quit)
>         && !(CONSP (wait_proc->status) && EQ (XCAR (wait_proc->status), Qexit)))
>       message ("Blocking call to accept-process-output with quit inhibited!!");
  
Good catch, please install it,


        Stefan