From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alain Schneble Newsgroups: gmane.emacs.bugs Subject: bug#22789: 25.1.50; In last master build https connections stop working Date: Mon, 7 Mar 2016 23:21:56 +0100 Message-ID: <86bn6qylmj.fsf@realize.ch> References: <864mcyo14y.fsf@Lenovo-PC.i-did-not-set--mail-host-address--so-tickle-me> <834mctbitq.fsf@gnu.org> <868u25p3m2.fsf@realize.ch> <83io18ahya.fsf@gnu.org> <86y4a3on6f.fsf@realize.ch> <87oaazg7fv.fsf@gnus.org> <86twkro0vr.fsf@realize.ch> <83d1rf8ifj.fsf@gnu.org> <86povfnm9r.fsf@realize.ch> <8337sa9865.fsf@gnu.org> <86bn6ynrbw.fsf@realize.ch> <83vb566v5b.fsf@gnu.org> <83d1razkmq.fsf@gnu.org> <86egbqkwsb.fsf@realize.ch> <86a8mekjrb.fsf@realize.ch> <83k2lhxria.fsf@gnu.org> <86egbo232a.fsf@realize.ch> <83si04wx18.fsf@gnu.org> <8660wz1azm.fsf@realize.ch> <861t7n1970.fsf@realize.ch> <83mvqauv8l.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1457389461 15714 80.91.229.3 (7 Mar 2016 22:24:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Mar 2016 22:24:21 +0000 (UTC) Cc: larsi@gnus.org, j_l_domenech@yahoo.com, 22789@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 07 23:24:12 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ad3ZS-0005nm-HV for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Mar 2016 23:24:10 +0100 Original-Received: from localhost ([::1]:58979 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad3ZR-0001Bd-U8 for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Mar 2016 17:24:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad3ZO-0001BL-8O for bug-gnu-emacs@gnu.org; Mon, 07 Mar 2016 17:24:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ad3ZK-0001hJ-6c for bug-gnu-emacs@gnu.org; Mon, 07 Mar 2016 17:24:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41289) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad3ZK-0001hF-3J for bug-gnu-emacs@gnu.org; Mon, 07 Mar 2016 17:24:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1ad3ZJ-0005oV-QZ for bug-gnu-emacs@gnu.org; Mon, 07 Mar 2016 17:24:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alain Schneble Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Mar 2016 22:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22789-submit@debbugs.gnu.org id=B22789.145738938422279 (code B ref 22789); Mon, 07 Mar 2016 22:24:01 +0000 Original-Received: (at 22789) by debbugs.gnu.org; 7 Mar 2016 22:23:04 +0000 Original-Received: from localhost ([127.0.0.1]:38416 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1ad3YO-0005nH-FE for submit@debbugs.gnu.org; Mon, 07 Mar 2016 17:23:04 -0500 Original-Received: from clientmail.realize.ch ([46.140.89.53]:4991) by debbugs.gnu.org with smtp (Exim 4.84) (envelope-from ) id 1ad3YL-0005mY-VQ for 22789@debbugs.gnu.org; Mon, 07 Mar 2016 17:23:02 -0500 Original-Received: from rintintin.hq.realize.ch.lan.rit ([192.168.0.105]) by clientmail.realize.ch ; Mon, 7 Mar 2016 23:22:41 +0100 Original-Received: from MYNGB (192.168.66.64) by rintintin.hq.realize.ch.lan.rit (192.168.0.105) with Microsoft SMTP Server (TLS) id 15.0.516.32; Mon, 7 Mar 2016 23:22:05 +0100 In-Reply-To: <83mvqauv8l.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 07 Mar 2016 18:07:54 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (windows-nt) X-ClientProxiedBy: rintintin.hq.realize.ch.lan.rit (192.168.0.105) To rintintin.hq.realize.ch.lan.rit (192.168.0.105) 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: 208.118.235.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:114556 Archived-At: --=-=-= Content-Type: text/plain Eli Zaretskii writes: > I think this change should be installed regardless, as it fixes an > oversight. However, I think it needs to be augmented, because the > fact that FILE_CONNECT flag is set doesn't necessarily mean the > connection is in progress: it could have failed already. We need to > look at the status as well. > > The possible states of the FILE_CONNECT flag and the cp->status values > are: > > flag status description > ---------------------------------------------------------------------------- > ON STATUS_READ_READY reader thread is about to try connect > ON STATUS_READ_FAILED reader thread waits in _sys_wait_connect > ON STATUS_READ_SUCCEEDED reader thread successfully connected > ON STATUS_CONNECT_FAILED reader thread failed to connect > OFF STATUS_READ_ACKNOWLEDGED sys_select acknowledged successful connect > OFF STATUS_READ_READY reader thread is about to read > OFF STATUS_READ_IN_PROGRESS reader thread waits in _sys_read_ahead > OFF STATUS_READ_SUCCEEDED reader thread succeeded in reading > OFF STATUS_READ_FAILED reader thread failed to read > > So we should only return EWOULDBLOCK when FILE_CONNECT is set _and_ > the status is not STATUS_CONNECT_FAILED. If FILE_CONNECT is set, but > the status is STATUS_CONNECT_FAILED, we should instead return the > value computed from cp->errcode (if it is non-zero). There's an > example of that in sys_read. Thank you very much for these inputs. I rearranged the patch to include these two cases and removed another special case that should no longer be needed as it is covered by the first one. Is this what you had in mind? Do you agree with the change? Thanks. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename="0001-Resolve-non-blocking-socket-connection-issue-on-w32.patch" Content-Description: Patch >From 81295b036eb0a43dee968e8aa3f031030589cddd Mon Sep 17 00:00:00 2001 From: Alain Schneble Date: Mon, 7 Mar 2016 23:05:40 +0100 Subject: [PATCH] Resolve non-blocking socket connection issue on w32 * src/w32.c (sys_write): For non-blocking sockets, return immediately with EWOULDBLOCK if connection is still in progress. If connection attempt has failed already, return proper code stashed in cp->errcode. BTW, this ensures we do not temporarily turn the socket into blocking mode for the pfn_send call if the connection is in progress. It turned out that doing so causes arbitrary GnuTLS handshake failures on MS-Windows. (bug#22789) --- src/w32.c | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-) diff --git a/src/w32.c b/src/w32.c index ccf7cc3..c553152 100644 --- a/src/w32.c +++ b/src/w32.c @@ -8772,6 +8772,30 @@ sys_write (int fd, const void * buffer, unsigned int count) unsigned long nblock = 0; if (winsock_lib == NULL) emacs_abort (); + child_process *cp = fd_info[fd].cp; + + /* If this is a non-blocking socket whose connection is in + progress or terminated with an error already, return the + proper error code to the caller. */ + if (cp != NULL && (fd_info[fd].flags & FILE_CONNECT) != 0) + { + /* In case connection is in progress, ENOTCONN that would + result from calling pfn_send is not what callers expect. */ + if (cp->status != STATUS_CONNECT_FAILED) + { + errno = EWOULDBLOCK; + return -1; + } + /* In case connection failed, use the actual error code + stashed by '_sys_wait_connect' in cp->errcode. */ + else if (cp->errcode != 0) + { + pfn_WSASetLastError (cp->errcode); + set_errno (); + return -1; + } + } + /* TODO: implement select() properly so non-blocking I/O works. */ /* For now, make sure the write blocks. */ if (fd_info[fd].flags & FILE_NDELAY) @@ -8782,14 +8806,8 @@ sys_write (int fd, const void * buffer, unsigned int count) if (nchars == SOCKET_ERROR) { set_errno (); - /* If this is a non-blocking socket whose connection is in - progress, return the proper error code to the caller; - ENOTCONN is not what they expect . */ - if (errno == ENOTCONN && (fd_info[fd].flags & FILE_CONNECT) != 0) - errno = EWOULDBLOCK; - else - DebPrint (("sys_write.send failed with error %d on socket %ld\n", - pfn_WSAGetLastError (), SOCK_HANDLE (fd))); + DebPrint (("sys_write.send failed with error %d on socket %ld\n", + pfn_WSAGetLastError (), SOCK_HANDLE (fd))); } /* Set the socket back to non-blocking if it was before, -- 2.6.2.windows.1 --=-=-=--