Tarantool development patches archive
 help / color / mirror / Atom feed
From: Kirill Yukhin <kyukhin@tarantool.org>
To: "Alexander V. Tikhonov" <avtikhon@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org,
	Vladislav Shpilevoy <v.shpilevoy@tarantool.org>,
	Alexander Turenko <alexander.turenko@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH v2] test: flaky box/net.box_wait_connected_gh-3856
Date: Fri, 26 Jun 2020 12:52:10 +0300	[thread overview]
Message-ID: <20200626095210.f4oz3smb5knohw25@tarantool.org> (raw)
In-Reply-To: <4351b421b56115e2d8c35f60fdb5e8ba43a7b9fe.1592628521.git.avtikhon@tarantool.org>

Hello,

On 20 июн 07:50, Alexander V. Tikhonov wrote:
> From: Alexander Turenko <alexander.turenko@tarantool.org>
> 
> Found issue running test on FreeBSD VBox host:
> 
>  [011] --- box/net.box_wait_connected_gh-3856.result	Mon Jun 15 09:39:49 2020
>  [011] +++ box/net.box_wait_connected_gh-3856.reject	Fri May  8 08:23:30 2020
>  [011] @@ -12,7 +12,8 @@
>  [011]  - opts:
>  [011]      wait_connected: false
>  [011]    host: 8.8.8.8
>  [011] -  state: initial
>  [011] +  state: error
>  [011] +  error: Invalid argument
>  [011]    port: '123456'
>  [011]  ...
>  [011]  c:close()
> 
> The reason of the fail was that getaddrinfo() returned EIA_SERVICE for an
> incorrect TCP/IP port on FreeBSD, but crops it as modulo of 65536 on
> Linux/glibc. Checked with local script './getaddrinfo':
> 
>   (Linux/glibc) $ ./getaddrinfo 8.8.8.8 123456
>   ----
>   family: AF_INET
>   socktype: SOCK_STREAM
>   protocol: IPPROTO_TCP
>   host: 8.8.8.8
>   serv: 57920
> 
>   (FreeBSD) $ ./getaddrinfo 8.8.8.8 123456
>   getaddrinfo: Service was not recognized for socket type
> 
> So obvious fix is to change 123456 to something less or equal to
> 65535. Say, 1234.
> 
> The test depended on an order in which fibers were scheduled
> (net_box.connect() creates a separate fiber for connecting in background
> using fiber.create(), which yields). Unlikely our fiber were not get
> execution time during the connection attempt, so it was more like a
> formal thing.
> 
> But we can decrease probability of this situation even more if we'll
> grab all connection fields just when net_box.connect() returns, not
> after yield in console (which is due to waiting a next command from
> test-run).
> 
> Closes #5083
> 
> Reviewed-by: Alexander V. Tikhonov <avtikhon@tarantool.org>

I've checked your patch into 1.10, 2.3, 2.4 and master.

--
Regards, Kirill Yukhin

      parent reply	other threads:[~2020-06-26  9:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-20  4:50 Alexander V. Tikhonov
2020-06-21 15:50 ` Vladislav Shpilevoy
2020-06-22 14:07   ` Alexander V. Tikhonov
2020-06-21 18:41 ` Alexander Turenko
2020-06-22 14:05   ` Alexander V. Tikhonov
2020-06-26  9:52 ` Kirill Yukhin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200626095210.f4oz3smb5knohw25@tarantool.org \
    --to=kyukhin@tarantool.org \
    --cc=alexander.turenko@tarantool.org \
    --cc=avtikhon@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH v2] test: flaky box/net.box_wait_connected_gh-3856' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox