From patchwork Tue Aug 27 15:50:13 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sergio Durigan Junior X-Patchwork-Id: 34282 Received: (qmail 112333 invoked by alias); 27 Aug 2019 15:50:24 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 112325 invoked by uid 89); 27 Aug 2019 15:50:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.9 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=enter, proposing, refused, his X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Aug 2019 15:50:23 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 42E733084295; Tue, 27 Aug 2019 15:50:22 +0000 (UTC) Received: from psique.yyz.redhat.com (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4425E5D6B0; Tue, 27 Aug 2019 15:50:19 +0000 (UTC) From: Sergio Durigan Junior To: GDB Patches Cc: Bernhard Wodok , Paul Carroll , Sergio Durigan Junior Subject: [PATCH] Fix PR win32/24284: tcp_auto_retry doesn't work in MinGW Date: Tue, 27 Aug 2019 11:50:13 -0400 Message-Id: <20190827155013.31610-1-sergiodj@redhat.com> MIME-Version: 1.0 X-IsSubscribed: yes This was reported by Bernhard Wodok, along with a patch to fix the issue. I adjusted the patch a bit, and I'm submitting the patch on his behalf. According to Bernhard, the issue can be reproduced by doing: 1. start gdb 2. enter 'target remote :2345' 3. observe that it throws a "connection refused" error immediately instead of waiting and throwing a timeout error I.e., I believe it can be reproduced by our current tests, which is why I'm not proposing any extra tests here (well, I don't use nor have any Windows system to test this, so...). The problem happens because we call 'gdb_select' passing 0 as its first argument, which, when using MinGW, ends up using the 'gdb_select' version from mingw-hdep.c, and when the first argument is 0 this means that WaitForMultipleObjects will be called with 0 as its first argument as well. According to the MS API docs, this is forbidden: https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitformultipleobjects The proposed fix is simple: we just call Sleep when N == 0 (and when TIMEOUT is non-NULL), and return 0. It makes sense to me. Both Bernhard and Paul Carroll confirmed that the fix works. I'm Cc'ing Bernhard in case you have any questions about the patch. OK? gdb/ChangeLog: 2019-08-27 Bernhard Wodok Sergio Durigan Junior PR win32/24284 * mingw-hdep.c (gdb_select): Handle case when 'n' is zero. --- gdb/mingw-hdep.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/gdb/mingw-hdep.c b/gdb/mingw-hdep.c index 44fb22e9a1..1710251c51 100644 --- a/gdb/mingw-hdep.c +++ b/gdb/mingw-hdep.c @@ -64,6 +64,17 @@ gdb_select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, int num_ready; size_t indx; + if (n == 0) + { + /* The MS API says that the first argument to + WaitForMultipleObjects cannot be zero. That's we just use + a regular Sleep here. */ + if (timeout != NULL) + Sleep (timeout->tv_sec * 1000 + timeout->tv_usec / 1000); + + return 0; + } + num_ready = 0; num_handles = 0; num_scbs = 0;