Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[System.Net.Sockets] flakey failures of SocketTest.TestSelect1 on Darwin systems #8360

Closed
lewurm opened this issue Apr 20, 2018 · 6 comments · Fixed by VincentDondain/mono#1 or #13152

Comments

@lewurm
Copy link
Member

@lewurm lewurm commented Apr 20, 2018

I couldn't reproduce it locally yet, but it seems to happen often enough.

I first saw it on the XI 2018-02 device tests run:
xamarin/xamarin-macios#3402 (comment)

later in the tvOS simulator, again for XI 2018-02:
xamarin/xamarin-macios#3402 (comment)

and now the mono OS X i386 lane (master):
https://jenkins.mono-project.com/job/test-mono-pull-request-i386-osx/9798/testReport/junit/(root)/SocketTest/TestSelect1/

@lewurm

This comment has been minimized.

Copy link
Member Author

@lewurm lewurm commented Apr 20, 2018

can someone with knowledge in this area verify that the test itself does make sense?

public void TestSelect1 ()
{
Socket srv = CreateServer (NetworkHelpers.FindFreePort ());
ClientSocket clnt = new ClientSocket (srv.LocalEndPoint);
Thread th = new Thread (new ThreadStart (clnt.ConnectSleepClose));
Socket acc = null;
try {
th.Start ();
acc = srv.Accept ();
clnt.Write ();
ArrayList list = new ArrayList ();
ArrayList empty = new ArrayList ();
list.Add (acc);
Socket.Select (list, empty, empty, 100);
Assert.AreEqual (0, empty.Count, "#01");
Assert.AreEqual (1, list.Count, "#02");
Socket.Select (empty, list, empty, 100);
Assert.AreEqual (0, empty.Count, "#03");
Assert.AreEqual (1, list.Count, "#04");
Socket.Select (list, empty, empty, -1);
Assert.AreEqual (0, empty.Count, "#05");
Assert.AreEqual (1, list.Count, "#06");
// Need to read the 10 bytes from the client to avoid a RST
byte [] bytes = new byte [10];
acc.Receive (bytes);
} finally {
if (acc != null)
acc.Close ();
srv.Close ();
}
}
static Socket CreateServer (int port)
{
Socket sock = new Socket (AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
sock.Bind (new IPEndPoint (IPAddress.Loopback, port));
sock.Listen (1);
return sock;
}
class ClientSocket {
Socket sock;
EndPoint ep;
public ClientSocket (EndPoint ep)
{
this.ep = ep;
sock = new Socket (AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
}
public void ConnectSleepClose ()
{
sock.Connect (ep);
Thread.Sleep (2000);
sock.Close ();
}
public void Write ()
{
byte [] b = new byte [10];
sock.Send (b);
}
}

@lewurm

This comment has been minimized.

Copy link
Member Author

@lewurm lewurm commented Apr 20, 2018

it looks like a bit fishy: Is Thread.Sleep used as a synchronisation primitive in this test?

@filipnavara

This comment has been minimized.

Copy link
Collaborator

@filipnavara filipnavara commented Apr 20, 2018

I am really concerned about the structure of the test... Can you try what happens if you:

  1. Add Thread.Sleep at the beginning of ConnectSleepClose method?
  2. Add Thread.Sleep between th.Start and srv.Accept calls?

I am almost certain it will affect the outcome one way or another and just show that the test has race condition.

@lewurm lewurm changed the title flakey failures of SocketTest.TestSelect1 on Darwin systems [System.Net.Sockets] flakey failures of SocketTest.TestSelect1 on Darwin systems Apr 20, 2018
lewurm added a commit to lewurm/mono that referenced this issue Apr 20, 2018
it makes the test less reliable. Potentially helps with
mono#8360
lewurm added a commit to lewurm/mono that referenced this issue Apr 20, 2018
it makes the test less reliable. Potentially helps with
mono#8360
@lewurm

This comment has been minimized.

Copy link
Member Author

@lewurm lewurm commented Apr 20, 2018

If I move clnt.Write () after the first Select (), it fails in the same way, but I don't know how this could happen with the current test. If I try what you suggested @filipnavara, it ends up with exceptions being thrown due to accessing a disposed object (which is a problem with this test case, but not the problem that we are seeing).

I submitted #8364 which at least gets rid of the one factor of uncertainty (thread).

@akoeplinger

This comment has been minimized.

Copy link
Member

@akoeplinger akoeplinger commented Apr 20, 2018

luhenry added a commit that referenced this issue Apr 20, 2018
it makes the test less reliable. Potentially helps with
#8360
monojenkins added a commit to monojenkins/mono that referenced this issue Apr 20, 2018
it makes the test less reliable. Potentially helps with
mono#8360
monojenkins added a commit to monojenkins/mono that referenced this issue Apr 20, 2018
it makes the test less reliable. Potentially helps with
mono#8360
luhenry added a commit that referenced this issue Apr 20, 2018
it makes the test less reliable. Potentially helps with
#8360
luhenry added a commit that referenced this issue Apr 20, 2018
it makes the test less reliable. Potentially helps with
#8360
@lewurm

This comment has been minimized.

Copy link
Member Author

@lewurm lewurm commented Apr 22, 2018

#8364 doesn't help, it's still happening: xamarin/xamarin-macios#3402 (comment)

VincentDondain added a commit to VincentDondain/mono that referenced this issue Feb 22, 2019
- Previous test with 100 micro second timeout would fail on iOS device when running **all the socket tests** about 3 times out of 5.
- With a 1 millisecond timeout, it didn't fail the 10 times I tried locally, hopefully this is enough to fix the flakiness.
- Fixes mono#8360: [System.Net.Sockets] flakey failures of SocketTest.TestSelect1 on Darwin systems
  (mono#8360)
- Also partial fix for maccore issue xamarin/maccore#1069
akoeplinger added a commit that referenced this issue Feb 22, 2019
- Previous test with 100 micro second timeout would fail on iOS device when running **all the socket tests** about 3 times out of 5.
- With a 1 millisecond timeout, it didn't fail the 10 times I tried locally, hopefully this is enough to fix the flakiness.
- Fixes #8360: [System.Net.Sockets] flakey failures of SocketTest.TestSelect1 on Darwin systems
  (#8360)
- Also partial fix for maccore issue xamarin/maccore#1069
akoeplinger added a commit that referenced this issue Feb 22, 2019
- Previous test with 100 micro second timeout would fail on iOS device when running **all the socket tests** about 3 times out of 5.
- With a 1 millisecond timeout, it didn't fail the 10 times I tried locally, hopefully this is enough to fix the flakiness.
- Fixes #8360: [System.Net.Sockets] flakey failures of SocketTest.TestSelect1 on Darwin systems
  (#8360)
- Also partial fix for maccore issue xamarin/maccore#1069

(cherry picked from commit 0525583)
akoeplinger added a commit that referenced this issue Feb 22, 2019
- Previous test with 100 micro second timeout would fail on iOS device when running **all the socket tests** about 3 times out of 5.
- With a 1 millisecond timeout, it didn't fail the 10 times I tried locally, hopefully this is enough to fix the flakiness.
- Fixes #8360: [System.Net.Sockets] flakey failures of SocketTest.TestSelect1 on Darwin systems
  (#8360)
- Also partial fix for maccore issue xamarin/maccore#1069

(cherry picked from commit 0525583)
alexanderkyte added a commit to alexanderkyte/mono that referenced this issue Mar 5, 2019
- Previous test with 100 micro second timeout would fail on iOS device when running **all the socket tests** about 3 times out of 5.
- With a 1 millisecond timeout, it didn't fail the 10 times I tried locally, hopefully this is enough to fix the flakiness.
- Fixes mono#8360: [System.Net.Sockets] flakey failures of SocketTest.TestSelect1 on Darwin systems
  (mono#8360)
- Also partial fix for maccore issue xamarin/maccore#1069
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Apr 24, 2019
Bumps to mono/api-snapshot@ae01378
Bumps to mono/reference-assemblies@e5173a5
Bumps to mono/bockbuild@d30329d
Bumps to mono/boringssl@3d87996
Bumps to mono/corefx@72f7d76
Bumps to mono/corert@1b7d4a1
Bumps to mono/helix-binaries@7e893ea
Bumps to mono/illinker-test-assets@f21ff68
Bumps to mono/linker@13d864e
Bumps to mono/llvm@1aaaaa5 [mono]
Bumps to mono/llvm@2c2cffe [xamarin-android]
Bumps to mono/NUnitLite@0029561
Bumps to mono/roslyn-binaries@0bbc9b4
Bumps to mono/xunit-binaries@8f6e62e

	$ git diff --shortstat 886c4901..e66c7667      # mono
        3597 files changed, 350850 insertions(+), 91128 deletions(-)
	$ git diff --shortstat 349752c464c5fc93b32e7d45825f2890c85c8b7d..2c2cffedf01e0fe266b9aaad2c2563e05b750ff4
	 240 files changed, 18562 insertions(+), 6581 deletions(-)

Context: dotnet/coreclr#22046

Fixes: CVE 2018-8292 on macOS
Fixes: http://work.devdiv.io/737323
Fixes: dotnet/corefx#33965
Fixes: dotnet/standard#642
Fixes: mono/mono#6997
Fixes: mono/mono#7326
Fixes: mono/mono#7517
Fixes: mono/mono#7750
Fixes: mono/mono#7859
Fixes: mono/mono#8360
Fixes: mono/mono#8460
Fixes: mono/mono#8766
Fixes: mono/mono#8922
Fixes: mono/mono#9418
Fixes: mono/mono#9507
Fixes: mono/mono#9951
Fixes: mono/mono#10024
Fixes: mono/mono#10030
Fixes: mono/mono#10038
Fixes: mono/mono#10448
Fixes: mono/mono#10735
Fixes: mono/mono#10735
Fixes: mono/mono#10737
Fixes: mono/mono#10743
Fixes: mono/mono#10834
Fixes: mono/mono#10837
Fixes: mono/mono#10838
Fixes: mono/mono#10863
Fixes: mono/mono#10945
Fixes: mono/mono#11020
Fixes: mono/mono#11021
Fixes: mono/mono#11021
Fixes: mono/mono#11049
Fixes: mono/mono#11091
Fixes: mono/mono#11095
Fixes: mono/mono#11123
Fixes: mono/mono#11138
Fixes: mono/mono#11146
Fixes: mono/mono#11202
Fixes: mono/mono#11214
Fixes: mono/mono#11317
Fixes: mono/mono#11326
Fixes: mono/mono#11378
Fixes: mono/mono#11385
Fixes: mono/mono#11478
Fixes: mono/mono#11479
Fixes: mono/mono#11488
Fixes: mono/mono#11489
Fixes: mono/mono#11527
Fixes: mono/mono#11529
Fixes: mono/mono#11596
Fixes: mono/mono#11603
Fixes: mono/mono#11613
Fixes: mono/mono#11623
Fixes: mono/mono#11663
Fixes: mono/mono#11681
Fixes: mono/mono#11684
Fixes: mono/mono#11693
Fixes: mono/mono#11697
Fixes: mono/mono#11779
Fixes: mono/mono#11809
Fixes: mono/mono#11858
Fixes: mono/mono#11895
Fixes: mono/mono#11898
Fixes: mono/mono#11898
Fixes: mono/mono#11965
Fixes: mono/mono#12182
Fixes: mono/mono#12193
Fixes: mono/mono#12218
Fixes: mono/mono#12235
Fixes: mono/mono#12263
Fixes: mono/mono#12307
Fixes: mono/mono#12331
Fixes: mono/mono#12362
Fixes: mono/mono#12374
Fixes: mono/mono#12402
Fixes: mono/mono#12421
Fixes: mono/mono#12461
Fixes: mono/mono#12479
Fixes: mono/mono#12479
Fixes: mono/mono#12552
Fixes: mono/mono#12603
Fixes: mono/mono#12747
Fixes: mono/mono#12831
Fixes: mono/mono#12843
Fixes: mono/mono#12881
Fixes: mono/mono#13030
Fixes: mono/mono#13284
Fixes: mono/mono#13297
Fixes: mono/mono#13455
Fixes: mono/mono#13460
Fixes: mono/mono#13478
Fixes: mono/mono#13479
Fixes: mono/mono#13522
Fixes: mono/mono#13607
Fixes: mono/mono#13610
Fixes: mono/mono#13610
Fixes: mono/mono#13639
Fixes: mono/mono#13672
Fixes: mono/mono#13834
Fixes: mono/mono#13878
Fixes: mono/mono#6352
Fixes: mono/monodevelop#6898
Fixes: xamarin/maccore#1069
Fixes: xamarin/maccore#1407
Fixes: xamarin/maccore#604
Fixes: xamarin/xamarin-macios#4984
Fixes: xamarin/xamarin-macios#5289
Fixes: xamarin/xamarin-macios#5363
Fixes: xamarin/xamarin-macios#5381
Fixes: https://issuetracker.unity3d.com/issues/editor-crashes-with-g-logv-when-entering-play-mode-with-active-flowcanvas-script
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.