all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: contovob@tcd.ie, 24201@debbugs.gnu.org, eggert@cs.ucla.edu
Subject: bug#24201: 25.1.50; TLS connections sometimes hang
Date: Sat, 06 Jul 2019 14:16:01 +0200	[thread overview]
Message-ID: <m3lfxbgxz2.fsf@gnus.org> (raw)
In-Reply-To: <83muhs9x5i.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 05 Jul 2019 21:03:21 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

>> Yes, normally when this code is triggered by the timer, there's other
>> networking happening more or less at the same time.
>
> So maybe another process steals the response?

That's possible...

>> That's not what the doc string says, I think?
>> 
>> --
>> Optional second argument SECONDS and third argument MILLISEC
>> specify a timeout; return after that much time even if there is
>> no subprocess output.
>> --
>> 
>> "even if"...  
>
> But if output is available, accept-process-output will return
> immediately, so "even if" really means "if".

Yeah, that's true.  But it should, in an case, not keep spinning (much)
longer than the timeout, whether there's any output or not...

>> Without the JUST-THIS-ONE parameter, accept-process-output seems to loop
>> until the peer closes the connection.  And then control is returned to
>> Lisp world and the data is in the buffer.
>
> Since you are saying that the remote does respond, this would mean the
> responses get lost somehow, or are consumed by other filter functions.
> The question is how can that happen?

What I'm seeing happening if I instrument the loop in the Lisp part with:

	(while (and (memq (process-status stream) '(open run))
		    (not (re-search-forward end-of-command nil t)))
          (push (buffer-string) my-output-list)
	  (accept-process-output stream 0.05)
	  (goto-char start))

is that when Emacs hangs, and I `C-g' after half a minute, I will get 1
"" (empty string) entry in that list, so the timeout isn't heeded.
But -- in the buffer where this is happening, the data this is waiting
for is present, so Emacs got the response and put it into the buffer --
but then just kept on spinning in wait_reading_process_output,
apparently.

I'll add some instrumentation to that function now and try to figure out
why it's not heeding the timeout.  It's so annoying that I haven't been
able to make a simple test case to reproduce the error, though, because
the hang only happens once every few hours...

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





  reply	other threads:[~2019-07-06 12:16 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-11 13:20 bug#24201: 25.1.50; TLS connections sometimes hang Lars Ingebrigtsen
2016-08-15  2:35 ` Paul Eggert
2016-10-10 10:36   ` Eli Zaretskii
2016-10-10 10:54     ` Lars Ingebrigtsen
2016-10-10 11:23       ` Eli Zaretskii
2017-09-02 12:40         ` Eli Zaretskii
2017-09-02 13:04           ` Lars Ingebrigtsen
2017-09-02 14:21             ` Eli Zaretskii
2018-02-18 17:57               ` Lars Ingebrigtsen
2018-02-19 16:52                 ` Lars Ingebrigtsen
2018-02-19 17:56                   ` Paul Eggert
2018-02-19 18:16                     ` Lars Ingebrigtsen
2018-02-19 18:32                       ` Eli Zaretskii
2018-02-19 19:06                         ` Lars Ingebrigtsen
2018-02-19 19:57                           ` Eli Zaretskii
2018-02-19 20:39                             ` Lars Ingebrigtsen
2019-06-24 13:25                               ` Lars Ingebrigtsen
2019-06-24 19:20                                 ` Eli Zaretskii
2019-06-24 20:46                                   ` Lars Ingebrigtsen
2019-06-25 19:15                                     ` Lars Ingebrigtsen
2019-06-25 21:57                                       ` Lars Ingebrigtsen
2019-06-26 16:32                                         ` Eli Zaretskii
2019-06-27 10:34                                           ` Lars Ingebrigtsen
2019-06-27 13:25                                             ` Eli Zaretskii
2019-06-27 19:28                                               ` Lars Ingebrigtsen
2019-06-28  6:19                                                 ` Eli Zaretskii
2019-06-28  8:25                                                   ` Lars Ingebrigtsen
2019-06-28  8:34                                                     ` Eli Zaretskii
2019-06-28  9:55                                                       ` Lars Ingebrigtsen
2019-06-28 12:26                                                         ` Eli Zaretskii
2019-06-28 14:39                                             ` Basil L. Contovounesios
2019-06-28 14:50                                               ` Eli Zaretskii
2019-06-30 19:02                                                 ` Lars Ingebrigtsen
2019-07-04 13:04                                                   ` Lars Ingebrigtsen
2019-07-04 19:05                                                     ` Eli Zaretskii
2019-07-05 12:59                                                       ` Lars Ingebrigtsen
2019-07-05 18:03                                                         ` Eli Zaretskii
2019-07-06 12:16                                                           ` Lars Ingebrigtsen [this message]
2019-07-07 18:13                                                             ` Lars Ingebrigtsen
2019-07-07 18:18                                                               ` Eli Zaretskii
2019-07-08 16:38                                                                 ` Lars Ingebrigtsen
2020-08-03  6:00                                                                   ` Lars Ingebrigtsen
2019-07-05  8:21                                                     ` Eli Zaretskii
2019-07-05 13:13                                                       ` Lars Ingebrigtsen
2019-06-26 16:29                                       ` Eli Zaretskii
2018-02-19 18:37                       ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3lfxbgxz2.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=24201@debbugs.gnu.org \
    --cc=contovob@tcd.ie \
    --cc=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.