Age | Commit message (Collapse) | Author |
|
They weren't updated in the last 6 years and aren't helpful anymore (e.g. by causing unrelated matches during git grep searches).
|
|
Get rid of the Thread.Sleep calls that are prone to timing issues.
|
|
The format of the test assembly name changed in 860334ff45a8d1c5886b8dbcfadaf28ac55b9393
from System.Web_test_net_4_x.dll to net_4_x_System.Web_test.dll.
This fixes all the places where the old name was used.
|
|
|
|
|
|
|
|
clearly on mobile_static
|
|
not guaranteed, too flaky for bcl test suite
|
|
|
|
|
|
|
|
|
|
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=37848
|
|
|
|
Test cases for [#12205](https://bugzilla.xamarin.com/show_bug.cgi?id=12205)
|
|
d5768a7f141e2a579cbca26f76c791c215f4aabf
Setting the priority before starting a Thread doesn't work right now as there's no handle to the native
thread at that point (the current implementation doesn't store the priority, it just tries setting it
on the native thread) so the test would remember the default 'Normal' priority instead of 'BelowNormal',
causing the test to fail later on.
Added an assert to verify that the thread priority can be set before starting and disable the test for now.
Note: variable names 'before' and 'after' were switched in the test, fixed those as well.
|
|
from tvOS/watchOS.
|
|
referencesource impl
The CreateEncryptor_KeyNull and CreateDecryptor_KeyNull tests tried to verify the previous Mono
behavior of throwing a CryptographicException when a null key is passed to the methods [1].
However, with the move to referencesource this no longer happens since when a null key is passed
a random one is generated instead [2].
The existing tests passed out of pure luck because a different CryptographicException is thrown later on:
```
System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed.
at System.Security.Cryptography.RijndaelManagedTransform.DecryptData (System.Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount, System.Byte[]& outputBuffer, Int32 outputOffset, PaddingMode paddingMode, Boolean fLast) [0x007b5] in /Users/alexander/dev/mono/external/referencesource/mscorlib/system/security/cryptography/rijndaelmanagedtransform.cs:751
at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock (System.Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount) [0x000bb] in /Users/alexander/dev/mono/external/referencesource/mscorlib/system/security/cryptography/rijndaelmanagedtransform.cs:336
at MonoTests.System.Security.Cryptography.RijndaelManagedTest.CreateDecryptor_KeyNull () [0x00066] in /Users/alexander/dev/mono/mcs/class/corlib/Test/System.Security.Cryptography/RijndaelManagedTest.cs:233
```
Unfortunately, sometimes it happens with the random key that this exception *doesn't* get thrown as the padding is valid, which makes the test randomly fail on Jenkins.
Deleting those tests is the simplest fix.
[1] https://github.com/mono/mono/blob/mono-4.0.0-branch/mcs/class/corlib/System.Security.Cryptography/RijndaelManagedTransform.cs#L107
[2] https://github.com/mono/referencesource/blob/33edf60ec4d35aba11850872777c8b3a484ca484/mscorlib/system/security/cryptography/rijndaelmanaged.cs#L66
|
|
RuntimeHelpers.RunClassConstructor (). Fixes #37313.
|
|
|
|
We didn't catch the regression that is fixed in a780c52749695141c2037a5828808a82880292f6
because the tests didn't check the actual string or that an OOM is raised.
Add a new test for creating a large string (which works on 64bit Mono) to test a similar
codepath.
|
|
|
|
|
|
[reflection] Fix MethodInfo.GetBaseDefinition for open constructed types (close #36305)
|
|
Fix bug #36414
|
|
When the base type of a generic type is an open constructed generic
type, GetBaseDefinition() must take the instantiation into account while
traversing the class hierarchy.
|
|
[reflection] Fix Type.GetProperties() for generic class instances
|
|
profile
This enables building the tests w/bitcode enabled on AppleTV (and they
were already excluded from the results anyway).
Part of the fix for
https://bugzilla.xamarin.com/show_bug.cgi?id=36569
|
|
|
|
|
|
|
|
|
|
different logic for single pattern extraction. Fixes part of #36003
|
|
In tests replace usages of Thread.Abort with Thread.Interrupt when it looks
like it can work, otherwise just disable the complete test.
|
|
TimeZoneInfo tests
|
|
|
|
|
|
slot in start_wrapper, otherwise Thread.CurrentThread would create a new Thread object so there would be two. Fixes #35828.
|
|
[corlib] Fixes TimeZoneInfo.ParseTZBuffer abbrevs.
|
|
Context: https://bugzilla.xamarin.com/show_bug.cgi?id=31432
Tests TimeZoneInfo.ParseTZBuffer with Europe/Moscow data that thrown
at System.ThrowHelper.ThrowKeyNotFoundException ()
at System.Collections.Generic.Dictionary`2[System.Int32,System.String].get_Item (Int32 key)mscorlib/system/collections/generic/dictionary.cs:176
at System.TimeZoneInfo.ParseTimesTypes (System.Byte[] buffer, Int32 index, Int32 count, System.Collections.Generic.Dictionary`2 abbreviations) [0x0002f] in mcs/class/corlib/System/TimeZoneInfo.cs:1293
at System.TimeZoneInfo.ParseTZBuffer (System.String id, System.Byte[] buffer, Int32 length)
|
|
|
|
[#35375](https://bugzilla.xamarin.com/show_bug.cgi?id=35375)
|
|
The `Sort<TKey, TValue> (TKey [] keys, TValue [] items, IComparer<TKey> comparer)` overload in Array throwed when keys.Length != items.Length.
However, on .NET you can pass in a keys array with fewer elements than in items and it'd sort the elements in items up to that point.
Fixed our implementation by only throwing when keys.Length > items.Length.
This was revealed by the coreclr/tests/src/CoreMangLib/cti/system/array/arraysort12.exe test.
I decided to port the test into our testsuite so we catch regressions earlier.
|
|
This requires the symbol writer which is not available on Android.
|
|
In addition to fixing the runtime, fix the test suite to correctly detect this problem.
This popped up because, for some reason, those two types have hashcodes that
don't return identity on reference sources.
|
|
The double.Epsilon value represent the smallest value that double is
able to represent. And that is diferent from the machine epsilon, which
is the smallest difference between two double values.
The second is equal to 2 ^ (-52), because there are 52bits to
represent the mantissa in a IEEE 754 double.
|
|
|
|
|
|
stack traces for all running threads.
|
|
|