[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24201: 25.1.50; TLS connections sometimes hang
From: |
Lars Ingebrigtsen |
Subject: |
bug#24201: 25.1.50; TLS connections sometimes hang |
Date: |
Sat, 06 Jul 2019 14:16:01 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
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
bug#24201: 25.1.50; TLS connections sometimes hang, Eli Zaretskii, 2019/07/05