- Jan 10, 2018
-
-
Zoltan Varga authored
[jit] Convert stores into sign/zero extensions for small ints during alias-analysis. Fixes gh #6414. (cherry picked from commit d32dfaad8fdd4a3a765aa4f2739f3df566d62a4f)
-
- Jan 09, 2018
-
-
Alexander Köplinger authored
Follow up to https://github.com/mono/mono/pull/6431, we should capture the exception that is passed to the methods. Copied the SetResult() method that referencesource uses. (cherry picked from commit ad5703ad)
-
Miguel de Icaza authored
-
- Jan 03, 2018
-
-
Marek Safar authored
-
- Jan 02, 2018
-
-
Brendan Zagaeski authored
Also ensure that WebConnection calls nstream.EndRead(). Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=61002 This bug is a regression in HTTPS web request cancellation behavior first introduced on the 2017-06 branch by https://github.com/mono/mono/commit/1b5e0f73316ee7b83c8947bc738015443fabd7af. It is in fact resolved already for the master branch by the refactoring in https://github.com/mono/mono/pull/6125. But since that refactoring is too large to backport and since the master branch won't be integrated into a release for a while longer, it is worth adding a separate smaller fix for the older active development branches. This proposed fix is intentionally conservative in how it modifies `WebConnection.EndWrite()` and `WebConnection.EndRead()`. It makes sure to keep precisely the same return values and exceptions as before. The fix also makes a small change to the `Close()` method to avoid setting `nstream = null`. This allows any pending `EndWrite()`, `EndRead()`, or `ReadDone()` callbacks to use the `nstream` field even after `Close()` has run. This shouldn't cause any new garbage collection issues because the closed `WebConnection` object is not expected to live much longer than the `NetworkStream` object referenced by `nstream`. Example of the problem for canceling `HttpClient.SendAsync()` ============================================================= 1. `WebConnectionStream.SetHeadersAsync()` calls `WebConnection.BeginWrite()`, passing in an anonymous callback method that will later call `WebConnection.EndWrite()` when the asynchronous write operation completes [1]. 2. When the `CancellationToken` for the call to `HttpClient.SendAsync()` is notified about the cancellation, it calls `HttpWebRequest.Abort()` [2], which calls `WebConnection.Abort()`, which calls `WebConnection.Close()`. 3. `WebConnection.Close()` calls `Close()` on both the `MobileAuthenticatedStream` and the network `Socket` and nulls out the `WebConnection`'s field references to those objects [3]. `MobileAuthenticatedStream.Close()` in turn calls `MobileAuthenticatedStream.Dispose()`, which sets the `lastException` field to an `ObjectDisposedException`. If the asynchronous write operation from step 1 is still in progress at this point, it will throw the `ObjectDisposedException`. 4. When `MobileAuthenticatedStream.StartOperation()` throws the `ObjectDisposedException` (thus completing the running Task), the anonymous callback method from step 1 gets invoked, and it calls `WebConnection.EndWrite()`. 5. The problem is that now `WebConnection.EndWrite()` fails to call `MobileAuthenticatedStream.EndWrite()`. There are 2 parts of the problem: (a) `WebConnection.EndWrite()` always returns _before_ calling `MobileAuthenticatedStream.EndWrite()` [4] because the call to `Abort()` at step 2 has set the request status to canceled [5]. (b) Even if the cancellation status check weren't there, the attempt to call `MobileAuthenticatedStream.EndWrite()` still wouldn't work because `Close()` has set the reference to the stream to `null` at step 3. The proposed fix addresses (a) by rearranging `WebConnection.EndWrite()` and `WebConnection.EndRead()` so that they _always_ call the corresponding `MobileAuthenticatedStream` methods. It addresses (b) by removing the line in `Close()` that sets the `nstream` field to `null`. How did mono/2017-06 commit 1b5e0f73 introduce this problem? =========================================================== Commit 1b5e0f73 uses Tasks and the `TaskToApm()` helper method _correctly_, so by itself it's OK. The problem is that the older `WebConnection` methods already had underlying limitations _before_ commit 1b5e0f73. In the Asynchronous Programming Model, "for each call to BeginOperationName, the application should also call EndOperationName to get the results of the operation" [6]. But `WebConnection` did not strictly follow this rule. For example, `WebConnection.EndWrite()` did _not_ always call `MobileAuthenticatedStream.EndWrite()`. This imprecise behavior worked until now because unlike unobserved exceptions in Tasks, "unobserved" exceptions in AsyncResult objects don't trigger any behaviors when the objects are finalized. (The exceptions are just discarded.) But now that `MobileAuthenticatedStream.BeginWrite()` uses Tasks behind the scenes, `WebConnection` needs to be stricter about following the rules. Testing the proposed fix against old bugs from `git blame` ========================================================== - Commit 613c2a91 https://bugzilla.xamarin.com/show_bug.cgi?id=31507 Results: Verified still fixed. I was able to reproduce the original behavior by intentionally removing the old fix. I then put the old fix back, added the new proposed changes, and verified that the test case still produced the good behavior (only task cancellation messages). - Commit 7584df6c Neither of the bugs mentioned in the commit message for 7584df6c appears to be related to the `Data.request` check. Since that check is the only part of the commit touched by the new proposed changes, neither of the bugs should be affected. But just to be thorough, I quickly ran through the test cases associated with those bugs. https://bugzilla.novell.com/show_bug.cgi?id=515931 Results: OK. I tried the test case from https://bugzilla.novell.com/show_bug.cgi?id=515097 with `AllowWriteStreamBuffering` set to `true` or `false`. The write operation started successfully in both cases, and the call to `Abort()` was able to cancel the operation as expected. https://bugzilla.novell.com/show_bug.cgi?id=510642 Results: OK. The test case still produced the expected overflow exception. References ========== [1] https://github.com/mono/mono/blob/b293f453027bc075ce636988b383451e5c346347/mcs/class/System/System.Net/WebConnectionStream.cs#L664-L666 [2] https://github.com/mono/mono/blob/b293f453027bc075ce636988b383451e5c346347/mcs/class/System.Net.Http/System.Net.Http/HttpClientHandler.cs#L347 [3] https://github.com/mono/mono/blob/b293f453027bc075ce636988b383451e5c346347/mcs/class/System/System.Net/WebConnection.cs#L1131-L1143 [4] https://github.com/mono/mono/blob/b293f453027bc075ce636988b383451e5c346347/mcs/class/System/System.Net/WebConnection.cs#L1033-L1034 [5] https://github.com/mono/mono/blob/b293f453027bc075ce636988b383451e5c346347/mcs/class/System/System.Net/WebConnection.cs#L1169 [6] https://docs.microsoft.com/dotnet/standard/asynchronous-programming-patterns/asynchronous-programming-model-apm
-
- Dec 20, 2017
-
-
Radek Doulik authored
We would like to include linker analyzer in the Xamarin.Android installation (https://github.com/xamarin/xamarin-android/issues/1093)
-
- Dec 17, 2017
-
-
Ludovic Henry authored
Fixes https://github.com/mono/mono/issues/6169
-
- Dec 16, 2017
-
-
Marek Habersack authored
Lack of it causes a build error in XA: CMake Error at [..]mono/external/boringssl/util/android-cmake/android.toolchain.cmake:800 (message): Specified Android native API level 'android-12' is not supported by your The set of minimum API levels in `configure.ac` is incorrect. The current NDK (r16) requires minimum API level of 14 for the 32-bit targets and level 21 for the 64-bit targets.
-
- Dec 14, 2017
-
-
Marek Safar authored
-
- Dec 05, 2017
-
-
Bernhard Urban authored
[2017-10][interp] fixes for interp AOT mode
-
Vlad Brezae authored
When we leave a try block and invoke finally blocks, we need to add try holes also for catch handlers, since they can invoke the previously handled finally blocks.
-
Vlad Brezae authored
-
Vlad Brezae authored
When doing an OP_CALL_HANDLER for a clause (from a leave opcode), all following instructions, up until the actual branch out of the try block, should be part of a hole for that clause. We were failing to account for a single leave instruction invoking multiple finally clauses sequentially, in which case a basic block can be a try hole for multiple clauses.
-
Vlad Brezae authored
This was inexplicably added as part of 2657d9cb, likely by mistake.
-
- Nov 29, 2017
-
-
Aleksey Kliger (λgeek) authored
If the constrained class is abstract, it might not implement the given method.
-
- Nov 28, 2017
-
-
Bernhard Urban authored
-
Bernhard Urban authored
-
Bernhard Urban authored
-
Bernhard Urban authored
signatures are coming from there: https://github.com/xamarin/xamarin-macios/blob/2d4256ef15f1ebf0b7f5774dee03a97a8c32f3a6/runtime/delegates.t4#L9
-
Alexander Köplinger authored
This mainly applies to Linux packaging.
-
Bernhard Urban authored
-
monojenkins authored
-
Rolf Bjarne Kvinge authored
-
Bernhard Urban authored
-
- Nov 27, 2017
-
-
Rolf Bjarne Kvinge authored
This shows up when Xamarin.Mac tests start defining XAMMAC [1] [1]: https://github.com/xamarin/xamarin-macios/pull/3034
-
- Nov 24, 2017
-
-
Alexander Köplinger authored
Backport of d3c7faa7 and 4535442e to 2017-10.
-
- Nov 23, 2017
-
-
Marek Safar authored
-
Rolf Bjarne Kvinge authored
-
Rolf Bjarne Kvinge authored
-
- Nov 22, 2017
-
-
-
Zoltan Varga authored
[aot] Add generic instances referenced by MONO_PATCH_INFO_METHOD_RGCTX patches. Fixes #60771. (#6075) Some generic instances were not generated because they were only referenced by METHOD_RGCTX patches, and the gsharedvt fallback didn't work because the method in question Unsafe.Add<T> uses a sizeof opcode on a gsharedvt type which is currently not supported. Testcase: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< using System; using System.Runtime.CompilerServices; public class Tests { [MethodImplAttribute (MethodImplOptions.NoInlining)] public void Foo55<T> () { byte[] arr = new byte [10]; ref byte data0 = ref arr [0]; Unsafe.Add (ref data0, 0); } interface IFace { void Foo55 <T> (); } class AClass : IFace { public void Foo55 <T> () { byte[] arr = new byte [10]; ref byte data0 = ref arr [0]; Unsafe.Add (ref data0, 0); } } public static int Main () { IFace iface = new AClass (); iface.Foo55<int> (); return 0; } } >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-
Aleksey Kliger (λgeek) authored
[loader] Rework get_method_constrained (Fixes #60545)
-
Ludovic Henry authored
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=56727
-
Alexander Köplinger authored
They changed with ef1ea85c and fbbde0f0.
-
- Nov 21, 2017
-
-
Martin Baulig authored
Implicitly add "Content-Length: 0" for all requests with a null body unless we're using a body-less HTTP Verb (HEAD, GET, MKCOL, CONNECT, TRACE). (cherry picked from commit 6beed5f7)
-
Aleksey Kliger authored
Fixes an interpreter failure in gtest-253.cs due to previous commit
-
- Nov 20, 2017
-
-
Chris Hamons authored
-
Aleksey Kliger authored
Instead of using find_method which relies on method name and exact signature matching (and thus can't work for variant interfaces), use the vtable and the interface offset to find the constrained method. Terminology: base method - a method of the base class to be called base class - some general class or interface that declares a method constraint class - a more specific class that also implements the method. constrained method - the version of the base method in the constraint class. To find the constrained method given the base method: - if the base class is a class: the constraint class can't be an interface. it's either the base class or some subclass of it. If the base method isn't virtual there's nothing to do the constrained method is the same one. If the base method is virtual, get its vtable slot and find the corresponding method in the constraint class's vtable. - if the base class is an interface: in this case the constraint class is either another interface or a class. if the constraint class is an interface, since interfaces can't have implementations, there's nothing to do. if the constraint class is a class, then to find the constrained method get the interface slot offset of the base method and find the base interface offset of the base interface and look in the constrained class vtable. (the base interface offset gives the starting vtable slot for the base interface in the constraint class vtable; the slot offsets go consecutively for each of the methods of the interface). Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=60545
-
- Nov 17, 2017
-
-
Alexis Christoforides authored
Bump cecil
-
Chris Hamons authored
-