From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Newsgroups: gmane.emacs.bugs Subject: bug#49449: 28: TLS connection never gets to "open" stage Date: Tue, 6 Jul 2021 21:12:39 +0200 Message-ID: Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30491"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen To: 49449@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 06 21:42:10 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m0qxO-0007ku-EO for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 06 Jul 2021 21:42:10 +0200 Original-Received: from localhost ([::1]:40568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m0qxN-0005V8-GI for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 06 Jul 2021 15:42:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40852) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m0qxG-0005Uj-M6 for bug-gnu-emacs@gnu.org; Tue, 06 Jul 2021 15:42:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38711) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m0qxG-00069I-Et for bug-gnu-emacs@gnu.org; Tue, 06 Jul 2021 15:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m0qxG-0004zs-70 for bug-gnu-emacs@gnu.org; Tue, 06 Jul 2021 15:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Jul 2021 19:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 49449 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.162560051319191 (code B ref -1); Tue, 06 Jul 2021 19:42:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 6 Jul 2021 19:41:53 +0000 Original-Received: from localhost ([127.0.0.1]:50257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0qx7-0004zT-4k for submit@debbugs.gnu.org; Tue, 06 Jul 2021 15:41:53 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:56182) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0qx5-0004zL-Bt for submit@debbugs.gnu.org; Tue, 06 Jul 2021 15:41:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40804) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m0qx5-0005PV-1x for bug-gnu-emacs@gnu.org; Tue, 06 Jul 2021 15:41:51 -0400 Original-Received: from mail1448c50.megamailservers.eu ([91.136.14.48]:34278 helo=mail265c50.megamailservers.eu) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m0qx2-00060S-KU for bug-gnu-emacs@gnu.org; Tue, 06 Jul 2021 15:41:50 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1625598762; bh=1dfDzG/Qu+DmDXdK1tYf/tvz4zW3M5X11apYX/t+cYU=; h=From:Subject:Date:Cc:To:From; b=e4MRCvFpC60CGgu+DRnbny7pCi3Q63kIsIdWjeWqNWYu2ruB3gJtDLk/wyHmz+ilm 6VsHbq4yVV2/I9wl9Ze+bNcjEgzOE37ecA6WB3lCrIIqpQqHHJ60WHH9Y2PQYGwJKw 2ofxfa/B51sNRrtpvB6Y39lxCdPrcNFx8XUNzjN4= Feedback-ID: mattiase@acm.or Original-Received: from [192.168.0.4] (c188-150-171-71.bredband.tele2.se [188.150.171.71]) (authenticated bits=0) by mail265c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 166JCdQG003392; Tue, 6 Jul 2021 19:12:41 +0000 X-Mailer: Apple Mail (2.3445.104.21) X-CTCH-RefID: str=0001.0A742F1B.60E4AB29.007B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=K5pc4BeI c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=mDV3o1hIAAAA:8 a=nbEulcdb89IEHmXGLgUA:9 a=CjuIK1q_8ugA:10 a=_FVE-zBwftR9WsbkzFJk:22 X-Origin-Country: SE Received-SPF: softfail client-ip=91.136.14.48; envelope-from=mattiase@acm.org; helo=mail265c50.megamailservers.eu X-Spam_score_int: -11 X-Spam_score: -1.2 X-Spam_bar: - X-Spam_report: (-1.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:209570 Archived-At: It seems that the process/TLS apparatus can get into a state where it is = unable to ever call the process sentinel "open\n" event; specifically, = an async `url-https` does not make forward progress until the connection = times out. This has been observed on macOS in Emacs 28 now and then, and it looks = like there is an invariant violation somewhere. To recap: The "open\n" event is sent to the sentinel in either of two places: (A) In finish_after_tls_connection, after having successfully called = nsm-verify-connection and the condition (fd_callback_info[p->outfd].flags & NON_BLOCKING_CONNECT_FD) =3D=3D 0 being satisfied (process.c:3277). (B) In wait_reading_process_output, after the descriptor being found = writable by `select` and the condition NILP (p->gnutls_boot_parameters) && !p->gnutls_p being satisfied (process.c:5900). There seems to be a gap in the logic, however: it is perfectly possible = for the condition in (A) to fail because the descriptor is still marked = nonblocking at that point, and for (B) to fail because gnutls_p=3Dtrue = was set already in gnutls_try_handshake. Lars, it looks like you wrote at least part of the original logic. Can = you see what is going on? It is somewhat complex. For reference, I'm using the reproduction recipe below; it may or may = not exhibit the problem in your particular setup. I'm using gnutls = 3.6.15. (defun busy-wait (s) (let ((t0 (current-time))) (while (< (time-to-seconds (time-since t0)) s) nil))) (progn (url-http #s(url "https" nil nil "elpa.gnu.org" nil = "/packages/archive-contents" nil nil t silent t t) (lambda (status) (message "callback: status =3D %S" status)) '(nil) nil 'tls) (busy-wait 1.0))