bug-gnu-emacs
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]