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: Sun, 28 Feb 2016 10:48:37 +0100 Message-ID: <868u25p3m2.fsf@realize.ch> References: <864mcyo14y.fsf@Lenovo-PC.i-did-not-set--mail-host-address--so-tickle-me> <87d1rmxl65.fsf@gnus.org> <86povm6qeu.wl-j_l_domenech@yahoo.com> <83k2lugeym.fsf@gnu.org> <871t81wtyt.fsf@gnus.org> <87r3g1veqc.fsf@gnus.org> <86si0euizj.fsf@realize.ch> <871t7xhj7t.fsf@gnus.org> <86oab1vjm9.fsf@realize.ch> <86d1rhpvcq.fsf@realize.ch> <834mctbitq.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1456653020 27245 80.91.229.3 (28 Feb 2016 09:50:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Feb 2016 09:50:20 +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 Sun Feb 28 10:50: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 1aZxzP-0006w5-QL for geb-bug-gnu-emacs@m.gmane.org; Sun, 28 Feb 2016 10:50:11 +0100 Original-Received: from localhost ([::1]:58200 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZxzP-000722-7z for geb-bug-gnu-emacs@m.gmane.org; Sun, 28 Feb 2016 04:50:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZxzL-0006zg-7d for bug-gnu-emacs@gnu.org; Sun, 28 Feb 2016 04:50:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZxzG-0005gM-QD for bug-gnu-emacs@gnu.org; Sun, 28 Feb 2016 04:50:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52386) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZxzG-0005gI-NL for bug-gnu-emacs@gnu.org; Sun, 28 Feb 2016 04:50:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aZxzG-0003qr-CH for bug-gnu-emacs@gnu.org; Sun, 28 Feb 2016 04:50:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alain Schneble Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 28 Feb 2016 09:50:02 +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.145665299314786 (code B ref 22789); Sun, 28 Feb 2016 09:50:02 +0000 Original-Received: (at 22789) by debbugs.gnu.org; 28 Feb 2016 09:49:53 +0000 Original-Received: from localhost ([127.0.0.1]:49513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZxz6-0003qQ-VM for submit@debbugs.gnu.org; Sun, 28 Feb 2016 04:49:53 -0500 Original-Received: from clientmail.realize.ch ([46.140.89.53]:2526) by debbugs.gnu.org with smtp (Exim 4.84) (envelope-from ) id 1aZxz4-0003qB-Mf for 22789@debbugs.gnu.org; Sun, 28 Feb 2016 04:49:51 -0500 Original-Received: from rintintin.hq.realize.ch.lan.rit ([192.168.0.105]) by clientmail.realize.ch ; Sun, 28 Feb 2016 10:49:28 +0100 Original-Received: from MYNGB (192.168.250.224) by rintintin.hq.realize.ch.lan.rit (192.168.0.105) with Microsoft SMTP Server (TLS) id 15.0.516.32; Sun, 28 Feb 2016 10:49:03 +0100 In-Reply-To: <834mctbitq.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 28 Feb 2016 05:43:45 +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:114031 Archived-At: Eli Zaretskii writes: >> From: Alain Schneble >> Date: Sun, 28 Feb 2016 00:49:25 +0100 >> Cc: "Jos=E9 L. Dom=E9nech" >> , 22789@debbugs.gnu.org >>=20 >> Now, if I do... >>=20 >> if (errno =3D=3D 0) >> errno =3D EAGAIN; >>=20 >> ...just after the call to set_errno above, guess what: It seems to work! > > This must be conditioned on something that requires EAGAIN. Otherwise > overriding the errno of zero sounds like a bad idea to me. This was just a quick try, to better understand the behavior. Not a proposed solution. Excuse me for not being precise. > Why does the nchars =3D=3D SOCKET_ERROR happen here at all, if winsock > returns with an error of zero? Isn't that strange? Exactly, this was what I meant in the part you elided: Alain Schneble writes: > At least for me, it will be an exercise for tomorrow to find the reason > why pfn_WSAGetLastError returns 0 in this case. I just had some time to investigate it further. The WSAGetLastError gets overridden in the call to pfn_ioctlsocket. That's why errno is 0. If I swap the order of the if statements in sys_write to look as follows, then the reason for the SOCKET_ERROR is revealed: if (nchars =3D=3D SOCKET_ERROR) { DebPrint (("sys_write.send failed with error %d on socket %ld\n", pfn_WSAGetLastError (), SOCK_HANDLE (fd))); set_errno (); } /* Set the socket back to non-blocking if it was before, for other operations that support it. */ if (fd_info[fd].flags & FILE_NDELAY) { printf ("reset file_ndelay"); nblock =3D 1; pfn_ioctlsocket (SOCK_HANDLE (fd), FIONBIO, &nblock); } =3D> WSAENOTCONN (10057): Socket is not connected. So that's the prove it accesses the socket too early. Alas, even though it seems to help at least for the test code I tried, turning WSAENOTCONN into EAGAIN seems wrong after all. It shouldn't try to write to the socket before it is connected at all...(?) Also the code "wraps" pfn_send and turns it into a blocking call. Not sure what the implications are... Nevertheless, don't you think the error handling in this code section is not very elaborate and switching the order as shown above might be better anyway? sys_write is primarily about writing, not about switching from non-blocking to blocking and back again... Or shall it somehow aggregate possible errors of both calls (pfn_send and pfn_ioctlsocket)?