From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#24201: 25.1.50; TLS connections sometimes hang Date: Sat, 06 Jul 2019 14:16:01 +0200 Message-ID: References: <6e9f3b6c-43df-bf95-d346-56c93c61b4d7@cs.ucla.edu> <83o9kk96ez.fsf@gnu.org> <83h8qc92hc.fsf@gnu.org> <834l4en63b.fsf@gnu.org> <83h88cjoiv.fsf@gnu.org> <87ftntkc53.fsf@tcd.ie> <83sgrthih6.fsf@gnu.org> <835zohboyc.fsf@gnu.org> <83muhs9x5i.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="197629"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: contovob@tcd.ie, 24201@debbugs.gnu.org, eggert@cs.ucla.edu To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jul 06 14:17:57 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hjjdd-000pHW-7A for geb-bug-gnu-emacs@m.gmane.org; Sat, 06 Jul 2019 14:17:57 +0200 Original-Received: from localhost ([::1]:59430 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hjjdc-000655-6u for geb-bug-gnu-emacs@m.gmane.org; Sat, 06 Jul 2019 08:17:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36496) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hjjcq-0005rf-Ba for bug-gnu-emacs@gnu.org; Sat, 06 Jul 2019 08:17:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hjjcm-0001PB-H6 for bug-gnu-emacs@gnu.org; Sat, 06 Jul 2019 08:17:07 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45517) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hjjcl-0001O8-Km for bug-gnu-emacs@gnu.org; Sat, 06 Jul 2019 08:17:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hjjcl-0004Xi-EE for bug-gnu-emacs@gnu.org; Sat, 06 Jul 2019 08:17:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Jul 2019 12:17:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24201 X-GNU-PR-Package: emacs Original-Received: via spool by 24201-submit@debbugs.gnu.org id=B24201.156241536914792 (code B ref 24201); Sat, 06 Jul 2019 12:17:03 +0000 Original-Received: (at 24201) by debbugs.gnu.org; 6 Jul 2019 12:16:09 +0000 Original-Received: from localhost ([127.0.0.1]:54333 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hjjbs-0003qC-If for submit@debbugs.gnu.org; Sat, 06 Jul 2019 08:16:08 -0400 Original-Received: from quimby.gnus.org ([80.91.231.51]:51666) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hjjbq-0003oI-OD for 24201@debbugs.gnu.org; Sat, 06 Jul 2019 08:16:07 -0400 Original-Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=stories) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hjjbm-0004OD-12; Sat, 06 Jul 2019 14:16:04 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAElBMVEXSSAvtrQn64gfliQpM AAFlAQX8KfDUAAACYklEQVQ4jVWUTZLcIAyFhTW9t+ACBi4gocx+qmLvnerx/a+SJ9ydqWjRdvPx kNCP6Zp2UhIpTo/5b4fR9b3vx8m5wUSUAnwHiJ+LZWutVM9FsXAEoVgnH320msXiNCxcExwnuayt FnfDWS9JAO1SuOYq3UyJP6cE4FQS8p4LTjIp5FNC++FKzb1KNbHUE/EvSAB+u5bk0nM3aMzVFcdf tLOze7Eq3n0rvGix74j0gL9F3bqP5mI1E2mcRV+FaDHGDVovvoqyF8R10FcnN0+CgEZei5Grxq3p +WCp/ClVJMvwwU3dIyVP7MbV/kQW64JEFskagIs1RPRpUIyCpEjN6wQiHvYw8Yqw3LP0jwkGkgfX ynd+JbeCDFOybD1Xa3BSM2qFN5ug1DwQUJs1BJDWUgDWUqGWdlu8txFgSVY0bW9Fym1tPBVMRIMS LSttJInSSstUrDQSUQqujFde1xts2G1EnFd62/SRlFmdCUVxfaLkjj0TxJbHeZ50nmjI+SYByBBO bnkmsbUuKJhOUMfM68i9Ztu2Vp3rBHzfbXndj3jUHp14ogIe/cCoqduKHu7bGWCprb/yAdUW7rZQ EEB9gxx7ZNGoB6XaXnkKhSCuRhMwVsYNRhuoc88xNHRS+6cYIaq9z/b5ovw/kBL32+mgpf3YyK3q HD/anyHBrdE2MynI/h4tGnMzV2YCelUuHzc4SDGDcZka48wlXKPbMWooQZRhGp7XDTBwUdTXsqk+ wjUm6jr2WJptGqM5PxUYWzyvYxJDG4XwFgBcByr6Y7eHCebH5+WDHvdBb4AnDuOXgyMW/gKo5ab4 Ov9kXgAAAABJRU5ErkJggg== In-Reply-To: <83muhs9x5i.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 05 Jul 2019 21:03:21 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:162209 Archived-At: Eli Zaretskii 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