| Age | Commit message (Collapse) | Author |
|---|
|
We sometimes see the following exception in the ServiceModel tests:
```
System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
at System.ThrowHelper.ThrowInvalidOperationException (ExceptionResource resource) [0x00000] in /var/lib/jenkins/workspace/test-mono-mainline/label/debian-amd64/external/referencesource/mscorlib/system/throwhelper.cs:99
at System.Collections.Generic.List`1+Enumerator[T].MoveNextRare () [0x00016] in /var/lib/jenkins/workspace/test-mono-mainline/label/debian-amd64/external/referencesource/mscorlib/system/collections/generic/list.cs:1180
at System.Collections.Generic.List`1+Enumerator[T].MoveNext () [0x00050] in /var/lib/jenkins/workspace/test-mono-mainline/label/debian-amd64/external/referencesource/mscorlib/system/collections/generic/list.cs:1174
at System.Linq.Enumerable.FirstOrDefault[TSource] (IEnumerable`1 source, System.Func`2 predicate) [0x00041] in /var/lib/jenkins/workspace/test-mono-mainline/label/debian-amd64/external/referencesource/System.Core/System/Linq/Enumerable.cs:960
at System.ServiceModel.Channels.Http.HttpListenerManager.TryDequeueRequest (System.ServiceModel.Dispatcher.ChannelDispatcher channel, TimeSpan timeout, System.ServiceModel.Channels.Http.HttpContextInfo& context) [0x00016] in /var/lib/jenkins/workspace/test-mono-mainline/label/debian-amd64/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpListenerManager.cs:93
at System.ServiceModel.Channels.Http.HttpListenerManager.TryDequeueRequest (System.ServiceModel.Dispatcher.ChannelDispatcher channel, TimeSpan timeout, System.ServiceModel.Channels.Http.HttpContextInfo& context) [0x000ab] in /var/lib/jenkins/workspace/test-mono-mainline/label/debian-amd64/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpListenerManager.cs:104
at System.ServiceModel.Channels.Http.HttpReplyChannel.TryReceiveRequest (TimeSpan timeout, System.ServiceModel.Channels.RequestContext& context) [0x00003] in /var/lib/jenkins/workspace/test-mono-mainline/label/debian-amd64/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpReplyChannel.cs:154
at System.ServiceModel.Channels.ReplyChannelBase+<BeginTryReceiveRequest>c__AnonStorey0.<>m__0 (TimeSpan tout, System.ServiceModel.Channels.RequestContext& ctx) [0x00056] in /var/lib/jenkins/workspace/test-mono-mainline/label/debian-amd64/mcs/class/System.ServiceModel/System.ServiceModel.Channels/ReplyChannelBase.cs:129
```
I managed to repro this consistently on the debian-7-x64-1 Jenkins machine by running the test in a loop with the following code for about 15mins:
while [ $? -eq 0 ]; do make check FIXTURE=System.ServiceModel.Dispatcher; done
The problem happens when RegisterListenerCommon/UnregisterListenerCommon is invoked through HttpChannelListener.OnOpen/OnAbort/OnClose which modifies the 'Entries' collection on another thread.
The fix is to add locking around the collection accesses.
|
|
RuntimeHelpers.RunClassConstructor (). Fixes #37313.
|
|
We were sometimes seeing the following test failure on Jenkins:
```
Test Case Failures:
1) MonoTests.System.Web.UI.WebControls.WizardStepBaseTest.WizardStepBase_Theme : System.IO.IOException : Sharing violation on path /var/folders/wm/jvn0yl0d39q9sm9glcrhdrmw0000gn/T/tmp672264ba.tmp/App_Themes/Theme1/WizardTest.skin
at System.IO.File.SetLastWriteTime (System.String path, DateTime lastWriteTime) [0x00029] in /Users/builder/jenkins/workspace/test-mono-mainline/label/osx-i386/mcs/class/corlib/System.IO/File.cs:474
at MonoTests.SystemWeb.Framework.WebTest.CopyBinary (System.Byte[] sourceArray, System.String targetUrl) [0x00098] in /Users/builder/jenkins/workspace/test-mono-mainline/label/osx-i386/mcs/class/System.Web/Test/mainsoft/NunitWeb/NunitWeb/WebTest.cs:364
at MonoTests.SystemWeb.Framework.WebTest.CopyResource (System.Type type, System.String resourceName, System.String targetUrl) [0x00059] in /Users/builder/jenkins/workspace/test-mono-mainline/label/osx-i386/mcs/class/System.Web/Test/mainsoft/NunitWeb/NunitWeb/WebTest.cs:307
at MonoTests.System.Web.UI.WebControls.WizardStepBaseTest.WizardStepBase_Theme () [0x00000] in /Users/builder/jenkins/workspace/test-mono-mainline/label/osx-i386/mcs/class/System.Web/Test/System.Web.UI.WebControls/WizardStepBaseTest.cs:311
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00038] in /Users/builder/jenkins/workspace/test-mono-mainline/label/osx-i386/mcs/class/corlib/System.Reflection/MonoMethod.cs:295
```
This happens because System.Web.UI.WebControls/ThemeTest.cs copies the WizardTest.skin file to the same App_Themes/Theme1 path in its setup method.
Since we're not interested in any particular theme in WizardStepBase_Theme we fix this by just using a different theme name (WizardStepBase instead of Theme1) so the two test fixtures don't clash.
|
|
|
|
|
|
|
|
|
|
It works fine now, the underlying mcs bug was fixed long ago.
|
|
Adds babysitter script for PR tests
|
|
[ServiceModel] Remove custom free port finder code
|
|
[runtime] Actually clean up context-static data segments.
|
|
Fix dot stuffing in SmtpClient
|
|
[WCF] ServiceHost should look for inherited ServiceBehaviorAttribute
|
|
We have a common one in NetworkHelpers now.
|
|
Fixes #37035
|
|
[ServiceModel] Make TcpReplyChannel.OnClose thread-safe
|
|
XmlObjectSerialier: fix ISerializable (bxc#37171)
|
|
The shim/bridge between Mono and the RS implementation of
XmlObjectSerializer, DataContractSerializer, etc. did not properly
invoke the constructor required by ISerializable, as it completely
omitted passing the populated SerializationInfo object.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=37171
|
|
We were seeing the following unhandled exception on Jenkins:
````
Unhandled exceptions:
1) MonoTests.System.ServiceModel.OperationContextTest.Current : System.NullReferenceException: Object reference not set to an instance of an object
at System.ServiceModel.Channels.NetTcp.TcpReplyChannel.OnClose (TimeSpan timeout) [0x00000] in /media/ssd/jenkins/workspace/test-mono-mainline/label/debian-armhf/mcs/class/System.ServiceModel/System.ServiceModel.Channels.NetTcp/TcpReplyChannel.cs:141
at System.ServiceModel.Channels.CommunicationObject.Close (TimeSpan timeout) [0x0001c] in /media/ssd/jenkins/workspace/test-mono-mainline/label/debian-armhf/mcs/class/System.ServiceModel/System.ServiceModel.Channels/CommunicationObject.cs:140
at System.ServiceModel.Channels.CommunicationObject.Close () [0x00000] in /media/ssd/jenkins/workspace/test-mono-mainline/label/debian-armhf/mcs/class/System.ServiceModel/System.ServiceModel.Channels/CommunicationObject.cs:131
at System.ServiceModel.Dispatcher.ListenerLoopManager.TryReceiveRequestDone (IAsyncResult result) [0x00027] in /media/ssd/jenkins/workspace/test-mono-mainline/label/debian-armhf/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/ChannelDispatcher.cs:583
```
This happens because multiple threads can call OnClose() and so `client` can be null.
Fixed this by taking code from HttpReplyChannel.OnClose which handled this already and also fixed the race condition there (the checks need to happen under a lock).
|
|
[XBuild] Fixed method invocation with string argument containing ",` or '
|
|
Without it we saw a " ./../../class/lib/net_4_x: Is a directory" error in the cygwin build.
|
|
Before this commit string value starting or ending with this char was malformed because Trim removed also part of string value
Also fixed recent regression from 42c0a94445 which failed to split arguments if doubleQuote was inside singleQuoute
|
|
|
|
|
|
Roslyn compiler
|
|
promotion. Fixes #37080
|
|
|
|
I see two problems with our current automated PR tests:
- Many false negatives— PR tests often fail due to recurring failures
unrelated to the PR
- Information about what failed is awkward to retrieve, scattered in
multiple places
This commit adds a Python script, `scripts/babysitter`. Currently our
Jenkins test suites are each run wrapped with the `timeout` command.
The babysitter acts as a drop-in replacement for GNU timeout but adds
the following features:
- Logs machine readable output about each test suite (as
line-delimited json)
- If the test suite uses NUnit, can detect if a test case failed or
crashed (terminated mono in mid-test), and retry unsuccessful tests
(up to a limit).
The reasoning here is that tests which fail inconsistently are
currently most likely due to one of our outstanding recurring failures
rather than the change made in the PR. Therefore, if a failing test
succeeds on retry, the PR itself is probably valid (although the
failure should be logged and looked at).
In addition to the script itself, changes to NUnit were required in
order to support the retry feature and allow fine-grained logging for
NUnit suites.
Major TODOs:
- Add retry support for our non-NUnit-based test suites
- Save the XML files NUnit produces (since reruns stomp XMLs from
previous runs)
- Add some kind of sensible feature for dealing with timeouts
|
|
|
|
If they exist, name-matched assemblies in the current directory will be embedded instead of the properly resolved ones.
|
|
[signcode] Change default hashing algorithm from MD5 to SHA1
|
|
|
|
|
|
|
|
[mkbundle] restore old behavior of -c flag
|
|
than one Main method)
|
|
**The Scenario**: `mono-api-info` and `mono-api-html`, together, are a
useful way to track API changes over time, specifically to check for
accidental API breakage:
# Have a "known good" assembly version;
# keep reference/assembly.xml in version control
$ mono-api-info assembly.dll > reference/assembly.xml
# ...then on every new build, check for breakage:
$ mono-api-info assembly.dll > new-assembly.xml
$ mono-api-html reference/assembly.xml new-assembly.xml > assembly-diff.html
$ if grep '<p>Removed' assembly-diff.html > /dev/null ; then \
echo "ABI BREAK IN assembly.dll" ; \
cat assembly-diff.html ; \
fi
This is a very nice workflow, and has been used in Xamarin.Android to
track accidental API breakage for some time.
**The problem** with the above workflow are *implicit* references:
`mono-api-info` will happily look for dependencies in the same
directory as `assembly`, but it will *also* look for assembly
references in various system-specific directories, which is fine...
...until it *isn't* fine, e.g. if you have your own version of
mscorlib.dll that you need to use, *not* the system one, as your own
version may have API differences from the system mscorlib.dll which
are "percolated" into `mono-api-info` output. For example, on
"desktop" profiles, System.Attribute implements
System.Runtime.InteropServices._Attribute, and thus *all* custom
attribute types will have _Attribute listed as an implemented
interface. The Xamarin.iOS and Xamarin.Android mscorlib.dll,
meanwhile, does *not* have System.Attribute implementing _Attribute.
Consequently, changing the mscorlib.dll which is used while processing
an assembly will change `mono-api-info` output, resulting in "API
breakage" which doens't actually exist, because the wrong mscorlib.dll
was used to generate the original API description in the first place.
We need a way to control which mscorlib.dll/etc. are used. This can be
done by allowing specification of the assembly search directories, so
that we can "override" the default system-specific directory location.
**The solution**: Add a `mono-api-info -L PATH` option which adds PATH
to the list of directories that `mono-api-info` will search when
resolving assembly references. This allows "overriding" the system
directory location, as PATH will be searched for mscorlib.dll before
the system directory location.
Additionally, add a `mono-api-info -r ASSEMBLY` option, which will
pre-process ASSEMBLY (and all dependencies) and add the directory
which contains ASSEMBLY to the assembly search paths.
These two options are conceptually similar to `mcs -L` and `mcs -r`.
Finally, while adding support for these options, add support for
`mono-api-info --help`, so that we don't need to use only the man page
to get option information.
|
|
[System.Runtime.Caching] Add missing locking when accessing cache entries
|
|
Add test and merge #1879
@monojenkins merge
|
|
[socket] Add test for SocketOptionName.MulticastTimeToLive
|
|
Bump xbuild script to 14.0 and a few other fixes
|
|
|
|
|
|
The mcs/class/Microsoft.Build.Tasks make check contains a test whose
goal is to verify that Microsoft.Build.Evaluation.Project can run a
MSBuild code fragment which has an assembly reference. The assembly
referenced in the test is System.Drawing. However on many systems
System.Drawing does not work without special setup. The test should
reference a different assembly (I picked System.Runtime.Serialization)
because ensuring System.Drawing is working isn't relevant to the test.
|
|
MD5 is considered insecure and switching the default to SHA1 should be better for everyone.
See the discussion on the mailing list: http://lists.ximian.com/pipermail/mono-devel-list/2015-December/043424.html
|
|
Add the new 4.5.2, 4.6 and 4.6.1 versions to Microsoft.Common.targets so xbuild doesn't print "warning : TargetFrameworkVersion 'v4.6.1' not supported by this toolset".
Additionally I found a bug in the target where "and" was used instead of "or" which means the condition was never true, fixed as well.
|
|
[HttpConnection] Bug fix: HttpListener's "IgnoreWriteExceptions" property value is ignored when "Expect: 100-Continue" header set in request
That problem was discussed previously here: https://github.com/mono/mono/pull/2300
I want to offer alternative solution now.
|
|
|
|
|
|
System.ServiceModel.Dispatcher.Bug32886.Bug32886_Test flakiness
|
