| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
System.Text.RegularExpressions (#5762)
|
|
|
|
|
|
|
|
* [System] Fix a few hardcoded socket ports in tests
Those could've shown up as "address already in use" in CI.
* [System.Runtime.Remoting] Fix a few hardcoded socket ports in tests
Those could've shown up as "address already in use" in CI.
Additionally remove a copy of RemotingServicesTest.cs from corlib
which also exists in System.Runtime.Remoting in updated form.
* [System.ServiceModel] Fix a few hardcoded socket ports in tests
Those could've shown up as "address already in use" in CI.
* [System.Net.Http] Fix a few hardcoded socket ports in tests
Those could've shown up as "address already in use" in CI.
The additional "keep-alive" header in Send_Complete_NoContent() and
Send_Transfer_Encoding_Chunked() is because we were using the same
port for all tests before so other tests would clear the header.
This doesn't happen now that we use distinct test ports.
* [System.ServiceModel.Web] Fix a few hardcoded socket ports in tests
Those could've shown up as "address already in use" in CI.
|
|
* [bcl] Grab free ports randomly in NetworkHelpers
We're frequently seeing "address already in use" errors on Jenkins.
The theory is that when we're running tests and grab the next free
port via our custom NetworkHelpers we're getting a port which will
also be returned to a simultaneously running test (e.g. another chroot)
because we're closing the TcpListener and thus releasing the port until
we start using it in actual test code. By that time the other test
might've already opened the port, causing our test to fail.
Instead we now try to use a random port in the range 10000-60000
and try if it's available. This doesn't completely fix the inherent
race but should hopefully make it way less likely.
|
|
reliable (#5209)
We've seen this test failure a few times:
```
MESSAGE:
#2
Expected: greater than or equal to 00:00:01
But was: 00:00:00.9544900
+++++++++++++++++++
STACK TRACE:
at MonoTests.Microsoft.Build.Execution.BuildSubmissionTest.EndBuildWaitsForSubmissionCompletion () [0x000d8] in /mnt/jenkins/workspace/test-mono-mainline-linux/label/ubuntu-1404-amd64/mcs/class/Microsoft.Build/Test/Microsoft.Build.Execution/BuildSubmissionTest.cs:110
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] in /mnt/jenkins/workspace/test-mono-mainline-linux/label/ubuntu-1404-amd64/mcs/class/corlib/System.Reflection/MonoMethod.cs:305
```
Rewriting the test to use Stopwatch instead of DateTime
for measuring elapsed time should make it more reliable.
|
|
It shouldn't throw in that case.
Helps cover https://bugzilla.xamarin.com/show_bug.cgi?id=57629
(note that we don't explicitly test on a readonly FS as that is hard
to do in a unit test, but running this test on Android should suffice).
|
|
BuildSubmissionTest.EndBuildWaitsForSubmissionCompletion
It started failing more frequently, let's see if we can get better data.
Also did the same change to a similar test.
|
|
TODO: we should refactor this, seems crazy to have a frankencopy of the test machinery in this folder.
|
|
NUnitHelper.cs adds CollectionAssert, FileAssert, StringAssert.
Also adds AssertHelper class with methods that are not part of nunitlite
Assert class.
|
|
There seems to be a race in some tests in the System test suite that use
SocketResponder on Windows. Some tests fail with an exception that the socket
has been closed before they get a chance to see the response sent by the
SocketResponder. The same happens occasionally when using SocketResponder on
.NET. This patch changes the order of the Socket.Shutdown() calls and adds a
Socket.Receive() before Shutdown() is called to give the sender a chance to
actually send any data before the responder shuts down and closes its side of
the connection.
|
|
|
|
A common pattern that we use across the test suite is to create objects on a new thread, join the thread, collect then expect certain objects to be dead/finalized since we assumed that thread to be no longer a source of pinning. This is not always the case since, after joining, the thread might still be alive and running unmanaged code related to the thread shutdown, which can reuse the stack that previously contained the managed references.
The workaround is to still allocate objects far down the stack, even if we are on a separate thread.
At the moment the helper can be used in tests which run under the TestDriver (since it's included in TestDriver.dll) and can also be included as a helper source for test bcl classes that need it.
|
|
|
|
This allow us catching and rethrowing the exception on the main thread, as well as making sure we wait for the Listen thread to finish in a timely manner.
|
|
In conjuction with `using` we ensure that we Start and Stop the SocketResponder correctly, and everytime
|
|
A number of fixes were made to the version in System but these fixes were never
applied to the System.Web.Services version. Merge the two and place the class
in the test-helpers directory to avoid this sort of maintenance problem.
|
|
Few tests using networking seem to fail due to
"Address already in use"
error that may be caused by opening listening
port too fast - because of some tests running
in parallel or because 2MSL TIME_WAIT period.
|
|
This helps in cases where two copies of the test suite are
running simultaneously, and both want to use the same hard-coded
ports in tests.
|
