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

WebException is thrown when reading from WebException.Response.GetResponse() stream #10645

Closed
galilov opened this issue Sep 17, 2018 · 31 comments · Fixed by #15220

Comments

@galilov
Copy link

@galilov galilov commented Sep 17, 2018

Steps to Reproduce

I use WebClient class to communicate with our server.
The code below checks the error and extracts a error message. It works under .Net 4.5 and .Net Core without any issues:

            if (e.Error is WebException we)
            {
                Console.WriteLine("ContentLength: {0}", we.Response.ContentLength);
                Console.WriteLine("ContentType: {0}", we.Response.ContentType);
                Console.WriteLine("Status: {0}", we.Status);
                var errorResponseStream = we.Response?.GetResponseStream();
                if (errorResponseStream != null)
                {
                    Console.WriteLine("before reader");
                    using (var reader = new StreamReader(errorResponseStream))
                    {
                        var response = reader.ReadToEnd();
                        Console.WriteLine("Response: {0}", response);
                        // some code here
                        return true;
                    }
                }
// some code here
            }

Current Behavior

bash-3.2$ mono TestConsoleApp.exe
ContentLength: 162
ContentType: application/json
Status: ProtocolError
before reader

Unhandled Exception:
System.Net.WebException: The request was canceled
  at ... 
SEE STACK TRACE BELOW

Expected Behavior

ContentLength: 162
ContentType: application/json
Status: ProtocolError
before reader
Response: {"status": "error", "errors": [{"location": "server", "name": "Error", "msgid": "CORE-96", "description": "This account already has the enrolled authenticator"}]}

On which platforms did you notice this

[x ] macOS
[x ] iOS

Version Used:

Mono JIT compiler version 5.12.0.301 (2018-02/4fe3280bba1 Fri Jul 20 08:25:42 EDT 2018)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: normal
SIGSEGV: altstack
Notification: kqueue
Architecture: amd64
Disabled: none
Misc: softdebug
Interpreter: yes
LLVM: yes(3.6.0svn-mono-master/8b1520c8aae)
GC: sgen (concurrent by default)

Stacktrace

System.Net.WebException: The request was canceled
  at System.Net.WebOperation.CheckThrowDisposed (System.Boolean throwIt, System.Runtime.ExceptionServices.ExceptionDispatchInfo& field) [0x00029] in <81ba78c8dc794b7f9f7b530c53db0f84>:0 
  at System.Net.WebOperation.ThrowIfClosedOrDisposed (System.Threading.CancellationToken cancellationToken) [0x00011] in <81ba78c8dc794b7f9f7b530c53db0f84>:0 
  at System.Net.WebOperation.ThrowIfClosedOrDisposed () [0x00006] in <81ba78c8dc794b7f9f7b530c53db0f84>:0 
  at System.Net.WebConnectionStream.Read (System.Byte[] buffer, System.Int32 offset, System.Int32 count) [0x00019] in <81ba78c8dc794b7f9f7b530c53db0f84>:0 
  at System.IO.StreamReader.ReadBuffer () [0x00028] in <f3f2aa82c3a04d48845485ce37124803>:0 
  at System.IO.StreamReader.ReadToEnd () [0x00052] in <f3f2aa82c3a04d48845485ce37124803>:0 
  at MobileSDK.Network.Connection`2[T,TAG].ProcessPossibleError (System.ComponentModel.AsyncCompletedEventArgs e) [0x0009b] in <1b02812293834acc819523c175008c85>:0 
  at MobileSDK.Network.Connection`2[T,TAG].UploadDataCompletedHandler (System.Object sender, System.Net.UploadDataCompletedEventArgs e) [0x0000e] in <1b02812293834acc819523c175008c85>:0 
  at System.Net.WebClient.OnUploadDataCompleted (System.Net.UploadDataCompletedEventArgs e) [0x0000a] in <81ba78c8dc794b7f9f7b530c53db0f84>:0 

@thangikcu

This comment has been minimized.

Copy link

@thangikcu thangikcu commented Sep 26, 2018

I got this issue too, please help us to check it @marek-safar

@marek-safar

This comment has been minimized.

Copy link
Member

@marek-safar marek-safar commented Sep 26, 2018

Do you have any self contained test we could use to help us verify this?

@thangikcu

This comment has been minimized.

Copy link

@thangikcu thangikcu commented Sep 27, 2018

Do you have any self contained test we could use to help us verify this?

Call a API with status response is 400

This is a simple code to verify

            try
             {
                WebClient webClient = new WebClient();

                webClient.Headers["Content-Type"] = "application/json";
                webClient.Headers["Accept"] = "*/*";
                webClient.Headers["Cache-Control"] = "no-cache";

                var fullUrl = new Uri("http://login");


                string s = await webClient.UploadStringTaskAsync(fullUrl, "POST", "{\n" +
                          "  \"langCode\": \"en\",\n" +
                          "  \"password\": \"123\",\n" +
                          "  \"username\": \"test2\"\n" +
                          "}");
            }
            catch (WebException webException)
            {
                var stream = webException.Response.GetResponseStream();

                using (var reader = new StreamReader(stream))
                {
                    try
                    {
                        var body = reader.ReadToEnd();
                    }
                    catch (Exception e)
                    {
                        e.ToString();
                    }
                }

            }`
@thangikcu

This comment has been minimized.

Copy link

@thangikcu thangikcu commented Sep 27, 2018

@marek-safar
In release note Mono 5.12.0. I think this impact for our issue

Class Libraries#
HttpWebRequest async handling has been rewritten. This resolves many long-standing and hard to reproduce issues involving requests cancellation or timeout. As HttpWebRequest is used as the underlying implementation by other types like HttpClient this should improve the reliability of a broad range of types.

@thangikcu

This comment has been minimized.

Copy link

@thangikcu thangikcu commented Sep 27, 2018

I downgrade xamarin android to version 8.3.3.2 and this issue not happen

@marek-safar

This comment has been minimized.

Copy link
Member

@marek-safar marek-safar commented Oct 3, 2018

@baulig this look like potential async rewrite issue

@baulig

This comment has been minimized.

Copy link
Member

@baulig baulig commented Oct 3, 2018

There was an issue (#10574) in the version of Mono that you're using that could cause problems when reading the response body from an error response. Are you still getting this problem with 2018-10?

@marek-safar

This comment has been minimized.

Copy link
Member

@marek-safar marek-safar commented Oct 12, 2018

@baulig could you check the attached repro does not fail now?

@lassana

This comment has been minimized.

Copy link

@lassana lassana commented Nov 13, 2018

I also observe it in our Xamarin.iOS application.

Stacktrace

System.Net.WebException
Message: The request was canceled
System.Net.WebOperation.ThrowIfClosedOrDisposed(System.Threading.CancellationToken cancellationToken) in <63f1529d84e54d74ba92c4719d33184c#b649a9968e11ba01a997bb250d8bb79c>:0
System.Net.WebOperation.ThrowIfClosedOrDisposed() in <63f1529d84e54d74ba92c4719d33184c#b649a9968e11ba01a997bb250d8bb79c>:0
System.Net.WebOperation.Run() in <63f1529d84e54d74ba92c4719d33184c#b649a9968e11ba01a997bb250d8bb79c>:0
 
System.Net.WebCompletionSource`1.WaitForCompletion() in <63f1529d84e54d74ba92c4719d33184c#b649a9968e11ba01a997bb250d8bb79c>:0
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task task) in <7d5a05cfcb09432d8cc656b9d781e54b#b649a9968e11ba01a997bb250d8bb79c>:0
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task task) in <7d5a05cfcb09432d8cc656b9d781e54b#b649a9968e11ba01a997bb250d8bb79c>:0
System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1+ConfiguredTaskAwaiter[TResult].GetResult() in <7d5a05cfcb09432d8cc656b9d781e54b#b649a9968e11ba01a997bb250d8bb79c>:0
System.Net.WebOperation.GetRequestStream() in <63f1529d84e54d74ba92c4719d33184c#b649a9968e11ba01a997bb250d8bb79c>:0

@filipnavara

This comment has been minimized.

Copy link
Collaborator

@filipnavara filipnavara commented Nov 28, 2018

I can reproduce this on Mono 5.16.0.220 (2018-06/bb3ae37d71a), the current Visual Studio for Mac Beta channel, when calling Google APIs. When the APIs result in error (eg. unauthorized access) the Google library tries to read the error description for the response in WebException, which results in another WebException being thrown.

Stack trace:

{System.Net.WebException: Value cannot be null.
Parameter name: src ---> System.ArgumentNullException: Value cannot be null.
Parameter name: src
  at System.Buffer.BlockCopy (System.Array src, System.Int32 srcOffset, System.Array dst, System.Int32 dstOffset, System.Int32 count) [0x00003] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.2.1.10/src/Xamarin.Mac/mcs/class/corlib/ReferenceSources/Buffer.cs:39 
  at System.Net.WebResponseStream+<ProcessRead>d__49.MoveNext () [0x00082] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.2.1.10/src/Xamarin.Mac/mcs/class/System/System.Net/WebResponseStream.cs:203 
   --- End of inner exception stack trace ---
  at System.Net.HttpWebRequest+<RunWithTimeoutWorker>d__241`1[T].MoveNext () [0x000b5] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.2.1.10/src/Xamarin.Mac/mcs/class/System/System.Net/HttpWebRequest.cs:951 
--- End of stack trace from previous location where exception was thrown ---
  at System.Net.WebConnectionStream.Read (System.Byte[] buffer, System.Int32 offset, System.Int32 count) [0x00070] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.2.1.10/src/Xamarin.Mac/mcs/class/System/System.Net/WebConnectionStream.cs:136 
  at System.IO.Compression.DeflateStreamNative.UnmanagedRead (System.IntPtr buffer, System.Int32 length) [0x00027] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.2.1.10/src/Xamarin.Mac/mcs/class/System/System.IO.Compression/DeflateStream.cs:432 
  at System.IO.Compression.DeflateStreamNative.UnmanagedRead (System.IntPtr buffer, System.Int32 length, System.IntPtr data) [0x00019] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.2.1.10/src/Xamarin.Mac/mcs/class/System/System.IO.Compression/DeflateStream.cs:423 
  at (wrapper native-to-managed) System.IO.Compression.DeflateStreamNative.UnmanagedRead(intptr,int,intptr)
  at (wrapper managed-to-native) System.IO.Compression.DeflateStreamNative.ReadZStream(System.IO.Compression.DeflateStreamNative/SafeDeflateStreamHandle,intptr,int)
  at System.IO.Compression.DeflateStreamNative.ReadZStream (System.IntPtr buffer, System.Int32 length) [0x00000] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.2.1.10/src/Xamarin.Mac/mcs/class/System/System.IO.Compression/DeflateStream.cs:405 
  at System.IO.Compression.DeflateStream.ReadInternal (System.Byte[] array, System.Int32 offset, System.Int32 count) [0x00027] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.2.1.10/src/Xamarin.Mac/mcs/class/System/System.IO.Compression/DeflateStream.cs:131 
  at System.IO.Compression.DeflateStream.Read (System.Byte[] array, System.Int32 offset, System.Int32 count) [0x00071] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.2.1.10/src/Xamarin.Mac/mcs/class/System/System.IO.Compression/DeflateStream.cs:161 
  at System.IO.Compression.GZipStream.Read (System.Byte[] array, System.Int32 offset, System.Int32 count) [0x00006] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.2.1.10/src/Xamarin.Mac/external/corefx/src/System.IO.Compression/src/System/IO/Compression/GZipStream.cs:84 
  at System.IO.StreamReader.ReadBuffer () [0x00028] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.2.1.10/src/Xamarin.Mac/mcs/class/referencesource/mscorlib/system/io/streamreader.cs:586 
  at System.IO.StreamReader.ReadToEnd () [0x00052] in /Library/Frameworks/Xamarin.Mac.framework/Versions/5.2.1.10/src/Xamarin.Mac/mcs/class/referencesource/mscorlib/system/io/streamreader.cs:451 
  at Google.Apis.Requests.ResponseExtensions.ReadToEnd (Google.Apis.Requests.IResponse response) [0x0000e] in /Users/filipnavara/Desktop/svn/trunk/Dependencies/GoogleApis/Apis/Requests/Response.cs:59 
  at Google.Apis.Discovery.BaseService.DeserializeError (Google.Apis.Requests.IResponse input) [0x0002f] in /Users/filipnavara/Desktop/svn/trunk/Dependencies/GoogleApis/Apis/Discovery/Service.cs:318 
  at Google.Apis.Requests.Request.HandleFailedRequest (Google.Apis.Requests.Request+AsyncExecutionState state, System.Net.WebException exception, Google.Apis.Requests.Request+AsyncRequestResult& asyncRequestResult) [0x00035] in /Users/filipnavara/Desktop/svn/trunk/Dependencies/

If there's any version I should test I will gladly do it. Note that the stack trace is different from the others listed above, but the general broken behavior is the same.

(Trying to make a simple repro- app, but I didn't succeed so far.)

@filipnavara

This comment has been minimized.

Copy link
Collaborator

@filipnavara filipnavara commented Nov 29, 2018

There's something really weird about it. If I make a plain Mono application in Visual Studio it seems to work just fine, but if I place the following code in Xamarin.Mac Cocoa app it crashes every time:

			// Do any additional setup after loading the view.
			var request = WebRequest.CreateHttp("https://www.googleapis.com/calendar/v3/users/me/calendarList");
			request.AutomaticDecompression = DecompressionMethods.Deflate | DecompressionMethods.GZip;
			request.Headers[HttpRequestHeader.Authorization] = "Bearer EXPIREDTOKEN";
			try
			{
				request.GetResponse();
			}
			catch (WebException e)
			{
				string error;
				using (var sr = new StreamReader(e.Response.GetResponseStream()))
				{
					// Should not crash here...
					error = sr.ReadToEnd();
				}
			}

This is second such occurrence where I could only reproduce the problem in Xamarin.Mac (despite checking the Mono version at runtime and it looked identical).

@filipnavara

This comment has been minimized.

Copy link
Collaborator

@filipnavara filipnavara commented Nov 29, 2018

Turns out that the runtime version is not identical afterall:

  • Mono console application with runtime "5.16.0.221 (2018-06/b63e5378e38 Mon Nov 19 17:43:10 EST 2018)" -> ok
  • Xamarin.Mac Cocoa Full/Modern "5.14.0 (explicit/000780ca82c)" -> NOT ok
  • Xamarin.Mac Cocoa with system framework "5.16.0.221 (2018-06/b63e5378e38 Mon Nov 19 17:43:10 EST 2018)" -> ok
  • Xamarin.Mac Cocoa master build "5.16.0 (explicit/b63e5378e38)" -> ok

I assume the problem is fixed, but unfortunately not in the current VS for Mac packages (Alpha / Beta as of today).

@filipnavara

This comment has been minimized.

Copy link
Collaborator

@filipnavara filipnavara commented Dec 11, 2018

The VS 2019 for Mac preview was released last week and along with it the "Xamarin Preview" channel with new versions of Mono and Xamarin toolsets. The issue seems to be solved for us with this preview. Can you confirm whether this is still happening for you with the new versions?

@marek-safar

This comment has been minimized.

Copy link
Member

@marek-safar marek-safar commented Dec 17, 2018

Closing based on @filipnavara additional testing

@carvalho-oak

This comment has been minimized.

Copy link

@carvalho-oak carvalho-oak commented Mar 24, 2019

This has been happening for more than 1 year... this ticket should be reopened.

@cuasijoe

This comment has been minimized.

Copy link

@cuasijoe cuasijoe commented May 15, 2019

This is still happening. This ticket should be reopened.

@marek-safar

This comment has been minimized.

Copy link
Member

@marek-safar marek-safar commented May 24, 2019

@marek-safar marek-safar reopened this May 24, 2019
@steveisok

This comment has been minimized.

Copy link
Contributor

@steveisok steveisok commented May 24, 2019

@carvalho-oak & @cuasijoe, what version(s) of mono are you running where you still see this?

@cuasijoe

This comment has been minimized.

Copy link

@cuasijoe cuasijoe commented May 24, 2019

@steveisok I'm using Mono.Framework 5.18.1 (using it on a Xamarin Forms Android project, updated to the most recent stable version)

@steveisok

This comment has been minimized.

Copy link
Contributor

@steveisok steveisok commented May 24, 2019

I can reproduce it on 5.18.1 on up to master. Definitely still an issue.

@baulig Since you've shuffled this around a bit, please take a look.

@baulig

This comment has been minimized.

Copy link
Member

@baulig baulig commented May 24, 2019

Using the test case from #10645 (comment), this is working just fine for me.

Using Xamarin.Mac 5.14.0.83 from the latest preview.

@steveisok

This comment has been minimized.

Copy link
Contributor

@steveisok steveisok commented May 24, 2019

@baulig, I am using this as a test and I can reproduce anywhere.

private static async Task RunMe()
    {
        try
        {
            WebClient webClient = new WebClient();

            webClient.Headers["Content-Type"] = "application/json";
            webClient.Headers["Accept"] = "*/*";
            webClient.Headers["Cache-Control"] = "no-cache";

            var fullUrl = new Uri("http://localhost");
            
            string s = await webClient.DownloadStringTaskAsync(fullUrl);
        }
        catch (WebException webException)
        {
            var stream = webException.Response.GetResponseStream();

            using (var reader = new StreamReader(stream))
            {
                try
                {
                    var body = reader.ReadToEnd();
                    Console.WriteLine("Exception Body: " + body);
                }
                catch (Exception eObj)
                {
                    Console.WriteLine("Exception: " + eObj.ToString());
                }
            }

        }
    }

I threw up a node server that just sends back a 400 status w/ a message.

@baulig

This comment has been minimized.

Copy link
Member

@baulig baulig commented May 24, 2019

Server

'use strict';

const express = require('express');

// Constants
const PORT = 8080;
const HOST = '0.0.0.0';

// App
const app = express();
app.get('/', (req, res) => {
	res.statusMessage = "This is an error";
	res.status(400).end();
});

app.listen(PORT, HOST);
console.log(`Running on http://${HOST}:${PORT}`);

The server sends

HTTP/1.1 400 This is an error
X-Powered-By: Express
Date: Fri, 24 May 2019 23:28:57 GMT
Connection: keep-alive
Content-Length: 0

@baulig

This comment has been minimized.

Copy link
Member

@baulig baulig commented May 24, 2019

Okay, this is a problem with WebClient and (since we're using the CoreFX version) should probably be reported there.

Look at this line here: https://github.com/mono/corefx/blob/1e09e26078fa86c03e16f4ff9fbfb1266cdf36df/src/System.Net.WebClient/src/System/Net/WebClient.cs#L919

It does this:

try {
   // ....
} catch (Exception e) when (!(e is OutOfMemoryException)) {
    exception = GetExceptionToPropagate(e);
    AbortRequest(request);
    writeStream?.Close();
}

Calling AbortRequest(request) there calls into HttpWebRequest.Abort() and then WebOperation.Abort(). Any subsequent attempt of reading from the connection will then fail.

@steveisok

This comment has been minimized.

Copy link
Contributor

@steveisok steveisok commented May 25, 2019

@baulig The test works for me in .net core. I targeted both 3.0 and 2.2 to test, so it might be a subtlety in mono.

@baulig

This comment has been minimized.

Copy link
Member

@baulig baulig commented Jun 3, 2019

It looks like CoreFX reads and buffers the entire error response before throwing the initial exception.

I vaguely remember that also thought about this when I wrote the code, but it was causing some problems / hangs for us. However, I'm not entirely sure about that.

@steveisok

This comment has been minimized.

Copy link
Contributor

@steveisok steveisok commented Jun 4, 2019

@baulig Since this works under other frameworks and is a pretty common use case, please make this work as expected. If you find there are some underlying issues, we can flush them out as they come.

@OladotunO

This comment has been minimized.

Copy link

@OladotunO OladotunO commented Jun 8, 2019

Hi All

I am working on a Xamarin.Andoid project, and I cannot get the full response from the server i am communicating with, it crashes at
"errorcode = r.ReadToEnd();"

            try
            {
                HtmlResult = wc.UploadString(configuredurl, postData);
            }
            catch (WebException e)
            {
                weberror = e.ToString();
                WebExceptionStatus status = e.Status;
                if (status == WebExceptionStatus.ProtocolError)
                {
                    // Get HttpWebResponse so that you can check the HTTP status code.  
                    HttpWebResponse httpResponse = (HttpWebResponse)e.Response;

                    using (StreamReader r = new StreamReader(((HttpWebResponse)e.Response).GetResponseStream()))
                    {
                        errorcode = r.ReadToEnd();
                    }


                }

            }
            finally
            {
            }

I found this thread while looking for a solution

@steveisok

This comment has been minimized.

Copy link
Contributor

@steveisok steveisok commented Jun 8, 2019

@OladotunO Looks like the same problem. Appreciate the extra info and we'll update this issue when we have a fix.

@javanjoel

This comment has been minimized.

Copy link

@javanjoel javanjoel commented Jun 16, 2019

Any workaround for this or suggestions? Really need the error messages from the server to respond on the client and this is holding us back from properly handling them.

akoeplinger added a commit that referenced this issue Jul 9, 2019
[System]: Allow reading fully buffered `HttpWebResponse` body after close.

If we have already read the entire response body, then we should allow the
user to read it even after the request has been aborted.

* `WebConnectionStream.Read ()`: Move `Operation.ThrowIfClosedOrDisposed ()`
   call down after argument checks and call a new protected abstract method
   called `TryReadFromBufferedContent ()` prior to it.

* `WebResponseStream.TryReadFromBufferedContent ()`: Implement it here.
  If the entire response body has been buffered, then `bufferedEntireContent`
  is true and `innerStream is BufferedReadStream` and we can call the new
  `BufferedReadStream.TryReadFromBuffer ()`.

* `WebResponseStream.ReadAllAsync ()`: Set `bufferedEntireContent = true`
   after reading the entire response body.

* `BufferedReadStream.TryReadFromBuffer ()`: New internal method.

Fixes #10645.
akoeplinger added a commit that referenced this issue Jul 10, 2019
[System]: Allow reading fully buffered `HttpWebResponse` body after close.

If we have already read the entire response body, then we should allow the
user to read it even after the request has been aborted.

* `WebConnectionStream.Read ()`: Move `Operation.ThrowIfClosedOrDisposed ()`
   call down after argument checks and call a new protected abstract method
   called `TryReadFromBufferedContent ()` prior to it.

* `WebResponseStream.TryReadFromBufferedContent ()`: Implement it here.
  If the entire response body has been buffered, then `bufferedEntireContent`
  is true and `innerStream is BufferedReadStream` and we can call the new
  `BufferedReadStream.TryReadFromBuffer ()`.

* `WebResponseStream.ReadAllAsync ()`: Set `bufferedEntireContent = true`
   after reading the entire response body.

* `BufferedReadStream.TryReadFromBuffer ()`: New internal method.

Fixes #10645.

Backport of #15220.
@waheedbhatti

This comment has been minimized.

Copy link

@waheedbhatti waheedbhatti commented Aug 19, 2019

Any workaround for this or suggestions? Really need the error messages from the server to respond on the client and this is holding us back from properly handling them.

Using HttpWebRequest instead of WebClient works fine.

jonpryor added a commit to xamarin/xamarin-android that referenced this issue Sep 6, 2019
Changes: http://github.com/mono/mono/compare/2c3aeaf3780de7392a0d3cbe4dcf86846eb4dffa...29b1ac19c961b959a09097dbc0fe4cd567cc5298

	$ git diff --shortstat 2c3aeaf3..29b1ac19
	 1528 files changed, 45421 insertions(+), 21967 deletions(-)

Changes: mono/api-doc-tools@d03e819...5da8127

	$ git diff --shortstat d03e8198..5da8127a
	 1001 files changed, 86168 insertions(+), 11863 deletions(-)

Changes: mono/api-snapshot@e09042d...1ca8e82

	$ git diff --shortstat e09042da..1ca8e82f
        28 files changed, 612 insertions(+), 217 deletions(-)

Changes: mono/cecil@a6c8f5e...cb6c1ca

	$ git diff --shortstat a6c8f5e1..cb6c1ca9
	 13 files changed, 233 insertions(+), 88 deletions(-)

Changes: mono/corefx@4806207...470e0e1

	$ git diff --shortstat 4806207f...470e0e10
	 4 files changed, 31 insertions(+), 12 deletions(-)

Changes: mono/linker@ebe2a1f...1f87de3

	$ git diff --shortstat ebe2a1f4...1f87de35
        90 files changed, 3219 insertions(+), 1224 deletions(-)

Changes: xamarin/java.interop@befdbc0...be6048e

	$ git diff --shortstat befdbc03...be6048ed
        3 files changed, 3 insertions(+), 3 deletions(-)

Upstream-Fixes: https://bugs.winehq.org/show_bug.cgi?id=47561
Upstream-Fixes: https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems/edit/967582
Upstream-Fixes: dotnet/coreclr#25071
Upstream-Fixes: dotnet/coreclr#25242
Upstream-Fixes: dotnet/coreclr#25632
Upstream-Fixes: dotnet/coreclr#25709
Upstream-Fixes: dotnet/corefx#37955
Upstream-Fixes: dotnet/corefx#38455
Upstream-Fixes: mono/mono#7377
Upstream-Fixes: mono/mono#8747
Upstream-Fixes: mono/mono#9621
Upstream-Fixes: mono/mono#9664
Upstream-Fixes: mono/mono#9706
Upstream-Fixes: mono/mono#10201
Upstream-Fixes: mono/mono#10645
Upstream-Fixes: mono/mono#10748
Upstream-Fixes: mono/mono#10848
Upstream-Fixes: mono/mono#12141
Upstream-Fixes: mono/mono#13311
Upstream-Fixes: mono/mono#13408
Upstream-Fixes: mono/mono#13412
Upstream-Fixes: mono/mono#13891
Upstream-Fixes: mono/mono#13923
Upstream-Fixes: mono/mono#13945
Upstream-Fixes: mono/mono#14170
Upstream-Fixes: mono/mono#14214
Upstream-Fixes: mono/mono#14214
Upstream-Fixes: mono/mono#14215
Upstream-Fixes: mono/mono#14243
Upstream-Fixes: mono/mono#14377
Upstream-Fixes: mono/mono#14495
Upstream-Fixes: mono/mono#14555
Upstream-Fixes: mono/mono#14724
Upstream-Fixes: mono/mono#14729
Upstream-Fixes: mono/mono#14772
Upstream-Fixes: mono/mono#14792
Upstream-Fixes: mono/mono#14793
Upstream-Fixes: mono/mono#14809
Upstream-Fixes: mono/mono#14830
Upstream-Fixes: mono/mono#14839
Upstream-Fixes: mono/mono#14841
Upstream-Fixes: mono/mono#14847
Upstream-Fixes: mono/mono#14864
Upstream-Fixes: mono/mono#14871
Upstream-Fixes: mono/mono#14917
Upstream-Fixes: mono/mono#14945
Upstream-Fixes: mono/mono#14946
Upstream-Fixes: mono/mono#14948
Upstream-Fixes: mono/mono#14957
Upstream-Fixes: mono/mono#14959
Upstream-Fixes: mono/mono#14960
Upstream-Fixes: mono/mono#14961
Upstream-Fixes: mono/mono#14963
Upstream-Fixes: mono/mono#14971
Upstream-Fixes: mono/mono#14972
Upstream-Fixes: mono/mono#14975
Upstream-Fixes: mono/mono#15023
Upstream-Fixes: mono/mono#15048
Upstream-Fixes: mono/mono#15058
Upstream-Fixes: mono/mono#15080
Upstream-Fixes: mono/mono#15182
Upstream-Fixes: mono/mono#15188
Upstream-Fixes: mono/mono#15189
Upstream-Fixes: mono/mono#15261
Upstream-Fixes: mono/mono#15262
Upstream-Fixes: mono/mono#15263
Upstream-Fixes: mono/mono#15265
Upstream-Fixes: mono/mono#15268
Upstream-Fixes: mono/mono#15307
Upstream-Fixes: mono/mono#15324
Upstream-Fixes: mono/mono#15329
Upstream-Fixes: mono/mono#15330
Upstream-Fixes: mono/mono#15441
Upstream-Fixes: mono/mono#15446
Upstream-Fixes: mono/mono#15503
Upstream-Fixes: mono/mono#15541
Upstream-Fixes: mono/mono#15551
Upstream-Fixes: mono/mono#15556
Upstream-Fixes: mono/mono#15596
Upstream-Fixes: mono/mono#15691
Upstream-Fixes: mono/mono#15692
Upstream-Fixes: mono/mono#15740
Upstream-Fixes: mono/mono#15751
Upstream-Fixes: mono/mono#15760
Upstream-Fixes: mono/mono#15781
Upstream-Fixes: mono/mono#15794
Upstream-Fixes: mono/mono#15825
Upstream-Fixes: mono/mono#15853
Upstream-Fixes: mono/mono#15878
Upstream-Fixes: mono/mono#15887
Upstream-Fixes: mono/mono#15990
Upstream-Fixes: mono/mono#16032
Upstream-Fixes: mono/mono#16411
Upstream-Fixes: mono/mono#16486
Upstream-Fixes: https://github.com/mono/mono/issues/25709
Upstream-Fixes: https://github.com/mono/mono/issues/38821
Upstream-Fixes: #3112
Upstream-Fixes: #3168

Update `build-tools/automation/build.groovy` so that it fully cleans
the build tree before starting the build, so that the vestigial mono
submodule (removed in 0c9f83b) is *actually* removed from the build
tree, so that we don't inadvertently use *ancient* submodule contents.
jonpryor added a commit to jonpryor/xamarin-android that referenced this issue Sep 6, 2019
Changes: http://github.com/mono/mono/compare/2c3aeaf3780de7392a0d3cbe4dcf86846eb4dffa...29b1ac19c961b959a09097dbc0fe4cd567cc5298

	$ git diff --shortstat 2c3aeaf3..29b1ac19
	 1528 files changed, 45421 insertions(+), 21967 deletions(-)

Changes: mono/api-doc-tools@d03e819...5da8127

	$ git diff --shortstat d03e8198..5da8127a
	 1001 files changed, 86168 insertions(+), 11863 deletions(-)

Changes: mono/api-snapshot@e09042d...1ca8e82

	$ git diff --shortstat e09042da..1ca8e82f
        28 files changed, 612 insertions(+), 217 deletions(-)

Changes: mono/cecil@a6c8f5e...cb6c1ca

	$ git diff --shortstat a6c8f5e1..cb6c1ca9
	 13 files changed, 233 insertions(+), 88 deletions(-)

Changes: mono/corefx@4806207...470e0e1

	$ git diff --shortstat 4806207f...470e0e10
	 4 files changed, 31 insertions(+), 12 deletions(-)

Changes: mono/linker@ebe2a1f...1f87de3

	$ git diff --shortstat ebe2a1f4...1f87de35
	 90 files changed, 3219 insertions(+), 1224 deletions(-)

Changes: xamarin/java.interop@75b1189...4fd3539

	$ git diff --shortstat 75b11891...4fd35393
	 34 files changed, 448 insertions(+), 52 deletions(-)

Upstream-Fixes: https://bugs.winehq.org/show_bug.cgi?id=47561
Upstream-Fixes: https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems/edit/967582
Upstream-Fixes: dotnet/coreclr#25071
Upstream-Fixes: dotnet/coreclr#25242
Upstream-Fixes: dotnet/coreclr#25632
Upstream-Fixes: dotnet/coreclr#25709
Upstream-Fixes: dotnet/corefx#37955
Upstream-Fixes: dotnet/corefx#38455
Upstream-Fixes: mono/mono#7377
Upstream-Fixes: mono/mono#8747
Upstream-Fixes: mono/mono#9621
Upstream-Fixes: mono/mono#9664
Upstream-Fixes: mono/mono#9706
Upstream-Fixes: mono/mono#10201
Upstream-Fixes: mono/mono#10645
Upstream-Fixes: mono/mono#10748
Upstream-Fixes: mono/mono#10848
Upstream-Fixes: mono/mono#12141
Upstream-Fixes: mono/mono#13311
Upstream-Fixes: mono/mono#13408
Upstream-Fixes: mono/mono#13412
Upstream-Fixes: mono/mono#13891
Upstream-Fixes: mono/mono#13923
Upstream-Fixes: mono/mono#13945
Upstream-Fixes: mono/mono#14170
Upstream-Fixes: mono/mono#14214
Upstream-Fixes: mono/mono#14214
Upstream-Fixes: mono/mono#14215
Upstream-Fixes: mono/mono#14243
Upstream-Fixes: mono/mono#14377
Upstream-Fixes: mono/mono#14495
Upstream-Fixes: mono/mono#14555
Upstream-Fixes: mono/mono#14724
Upstream-Fixes: mono/mono#14729
Upstream-Fixes: mono/mono#14772
Upstream-Fixes: mono/mono#14792
Upstream-Fixes: mono/mono#14793
Upstream-Fixes: mono/mono#14809
Upstream-Fixes: mono/mono#14830
Upstream-Fixes: mono/mono#14839
Upstream-Fixes: mono/mono#14841
Upstream-Fixes: mono/mono#14847
Upstream-Fixes: mono/mono#14864
Upstream-Fixes: mono/mono#14871
Upstream-Fixes: mono/mono#14917
Upstream-Fixes: mono/mono#14945
Upstream-Fixes: mono/mono#14946
Upstream-Fixes: mono/mono#14948
Upstream-Fixes: mono/mono#14957
Upstream-Fixes: mono/mono#14959
Upstream-Fixes: mono/mono#14960
Upstream-Fixes: mono/mono#14961
Upstream-Fixes: mono/mono#14963
Upstream-Fixes: mono/mono#14971
Upstream-Fixes: mono/mono#14972
Upstream-Fixes: mono/mono#14975
Upstream-Fixes: mono/mono#15023
Upstream-Fixes: mono/mono#15048
Upstream-Fixes: mono/mono#15058
Upstream-Fixes: mono/mono#15080
Upstream-Fixes: mono/mono#15182
Upstream-Fixes: mono/mono#15188
Upstream-Fixes: mono/mono#15189
Upstream-Fixes: mono/mono#15261
Upstream-Fixes: mono/mono#15262
Upstream-Fixes: mono/mono#15263
Upstream-Fixes: mono/mono#15265
Upstream-Fixes: mono/mono#15268
Upstream-Fixes: mono/mono#15307
Upstream-Fixes: mono/mono#15324
Upstream-Fixes: mono/mono#15329
Upstream-Fixes: mono/mono#15330
Upstream-Fixes: mono/mono#15441
Upstream-Fixes: mono/mono#15446
Upstream-Fixes: mono/mono#15503
Upstream-Fixes: mono/mono#15541
Upstream-Fixes: mono/mono#15551
Upstream-Fixes: mono/mono#15556
Upstream-Fixes: mono/mono#15596
Upstream-Fixes: mono/mono#15691
Upstream-Fixes: mono/mono#15692
Upstream-Fixes: mono/mono#15740
Upstream-Fixes: mono/mono#15751
Upstream-Fixes: mono/mono#15760
Upstream-Fixes: mono/mono#15781
Upstream-Fixes: mono/mono#15794
Upstream-Fixes: mono/mono#15825
Upstream-Fixes: mono/mono#15853
Upstream-Fixes: mono/mono#15878
Upstream-Fixes: mono/mono#15887
Upstream-Fixes: mono/mono#15990
Upstream-Fixes: mono/mono#16032
Upstream-Fixes: mono/mono#16411
Upstream-Fixes: mono/mono#16486
Upstream-Fixes: https://github.com/mono/mono/issues/25709
Upstream-Fixes: https://github.com/mono/mono/issues/38821
Upstream-Fixes: xamarin#3112
Upstream-Fixes: xamarin#3168

Update `build-tools/automation/build.groovy` so that it fully cleans
the build tree before starting the build, so that the vestigial mono
submodule (removed in 0c9f83b) is *actually* removed from the build
tree, so that we don't inadvertently use *ancient* submodule contents.
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Sep 7, 2019
Changes: http://github.com/mono/mono/compare/2c3aeaf3780de7392a0d3cbe4dcf86846eb4dffa...29b1ac19c961b959a09097dbc0fe4cd567cc5298

	$ git diff --shortstat 2c3aeaf3..29b1ac19
	 1528 files changed, 45421 insertions(+), 21967 deletions(-)

Changes: mono/api-doc-tools@d03e819...5da8127

	$ git diff --shortstat d03e8198..5da8127a
	 1001 files changed, 86168 insertions(+), 11863 deletions(-)

Changes: mono/api-snapshot@e09042d...1ca8e82

	$ git diff --shortstat e09042da..1ca8e82f
        28 files changed, 612 insertions(+), 217 deletions(-)

Changes: mono/cecil@a6c8f5e...cb6c1ca

	$ git diff --shortstat a6c8f5e1..cb6c1ca9
	 13 files changed, 233 insertions(+), 88 deletions(-)

Changes: mono/corefx@4806207...470e0e1

	$ git diff --shortstat 4806207f...470e0e10
	 4 files changed, 31 insertions(+), 12 deletions(-)

Changes: mono/linker@ebe2a1f...1f87de3

	$ git diff --shortstat ebe2a1f4...1f87de35
	 90 files changed, 3219 insertions(+), 1224 deletions(-)

Changes: xamarin/java.interop@75b1189...4fd3539

	$ git diff --shortstat 75b11891...4fd35393
	 34 files changed, 448 insertions(+), 52 deletions(-)

Fixes: #3112
Fixes: #3168

Context: https://bugs.winehq.org/show_bug.cgi?id=47561
Context: https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems/edit/967582
Context: dotnet/coreclr#25071
Context: dotnet/coreclr#25242
Context: dotnet/coreclr#25632
Context: dotnet/coreclr#25709
Context: dotnet/corefx#37955
Context: dotnet/corefx#38455
Context: mono/mono#7377
Context: mono/mono#8747
Context: mono/mono#9621
Context: mono/mono#9664
Context: mono/mono#9706
Context: mono/mono#10201
Context: mono/mono#10645
Context: mono/mono#10748
Context: mono/mono#10848
Context: mono/mono#12141
Context: mono/mono#13311
Context: mono/mono#13408
Context: mono/mono#13412
Context: mono/mono#13891
Context: mono/mono#13923
Context: mono/mono#13945
Context: mono/mono#14170
Context: mono/mono#14214
Context: mono/mono#14214
Context: mono/mono#14215
Context: mono/mono#14243
Context: mono/mono#14377
Context: mono/mono#14495
Context: mono/mono#14555
Context: mono/mono#14724
Context: mono/mono#14729
Context: mono/mono#14772
Context: mono/mono#14792
Context: mono/mono#14793
Context: mono/mono#14809
Context: mono/mono#14830
Context: mono/mono#14839
Context: mono/mono#14841
Context: mono/mono#14847
Context: mono/mono#14864
Context: mono/mono#14871
Context: mono/mono#14917
Context: mono/mono#14945
Context: mono/mono#14946
Context: mono/mono#14948
Context: mono/mono#14957
Context: mono/mono#14959
Context: mono/mono#14960
Context: mono/mono#14961
Context: mono/mono#14963
Context: mono/mono#14971
Context: mono/mono#14972
Context: mono/mono#14975
Context: mono/mono#15023
Context: mono/mono#15048
Context: mono/mono#15058
Context: mono/mono#15080
Context: mono/mono#15182
Context: mono/mono#15188
Context: mono/mono#15189
Context: mono/mono#15261
Context: mono/mono#15262
Context: mono/mono#15263
Context: mono/mono#15265
Context: mono/mono#15268
Context: mono/mono#15307
Context: mono/mono#15324
Context: mono/mono#15329
Context: mono/mono#15330
Context: mono/mono#15441
Context: mono/mono#15446
Context: mono/mono#15503
Context: mono/mono#15541
Context: mono/mono#15551
Context: mono/mono#15556
Context: mono/mono#15596
Context: mono/mono#15691
Context: mono/mono#15692
Context: mono/mono#15740
Context: mono/mono#15751
Context: mono/mono#15760
Context: mono/mono#15781
Context: mono/mono#15794
Context: mono/mono#15825
Context: mono/mono#15853
Context: mono/mono#15878
Context: mono/mono#15887
Context: mono/mono#15990
Context: mono/mono#16032
Context: mono/mono#16411
Context: mono/mono#16486
Context: https://github.com/mono/mono/issues/25709
Context: https://github.com/mono/mono/issues/38821

Update `build-tools/automation/build.groovy` so that it fully cleans
the build tree before starting the build, so that the vestigial mono
submodule (removed in 0c9f83b) is *actually* removed from the build
tree, so that we don't inadvertently use *ancient* submodule contents.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.