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

HttpClient.SendAsync() with > 2 GB response body. #14214

Closed
grendello opened this issue Apr 24, 2019 · 21 comments · Fixed by #14821 or xamarin/xamarin-android#3173

Comments

@grendello
Copy link
Member

@grendello grendello commented Apr 24, 2019

The crash:

Unhandled Exception:
System.Net.Http.HttpRequestException: Cannot write more bytes to the buffer than the configured maximum buffer size: 2147483647.
  at System.Net.Http.HttpClient.FinishSendAsyncBuffered (System.Threading.Tasks.Task`1[TResult] sendTask, System.Net.Http.HttpRequestMessage request, System.Threading.CancellationTokenSource cts, System.Boolean disposeCts) [0x0017e] in <ab6fe02f08ec49cf9a8cb0b216b150b1>:0 
  at a.GetDownloadSizeWithStatus (System.Uri url) [0x00070] in /tmp/t.cs:23 
  at a.Main (System.String[] args) [0x00024] in /tmp/t.cs:13 
  at a.<Main> (System.String[] args) [0x0000c] in <4a62cd9e55994628aaca3ee6fc5a4f64>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.Net.Http.HttpRequestException: Cannot write more bytes to the buffer than the configured maximum buffer size: 2147483647.
  at System.Net.Http.HttpClient.FinishSendAsyncBuffered (System.Threading.Tasks.Task`1[TResult] sendTask, System.Net.Http.HttpRequestMessage request, System.Threading.CancellationTokenSource cts, System.Boolean disposeCts) [0x0017e] in <ab6fe02f08ec49cf9a8cb0b216b150b1>:0 
  at a.GetDownloadSizeWithStatus (System.Uri url) [0x00070] in /tmp/t.cs:23 
  at a.Main (System.String[] args) [0x00024] in /tmp/t.cs:13 
at a.<Main> (System.String[] args) [0x0000c] in <4a62cd9e55994628aaca3ee6fc5a4f64>:0 

The program below reproduces the crash:

//
// Compile with: csc -r:System.Net.Http.dll t.cs -langversion:7.1
//
using System;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;

class a
{
	async static Task<int> Main (string[] args)
	{
		(bool success, ulong size, HttpStatusCode status) = await GetDownloadSizeWithStatus(new Uri ("https://xamjenkinsartifact.azureedge.net/mono-sdks/android-debug-Linux-e66c76674243826a8d127f0261f0fb64f8d59757.zip"));
		return 0;
	}

	public static async Task<(bool success, ulong size, HttpStatusCode status)> GetDownloadSizeWithStatus (Uri url)
	{
		using (var httpClient = new HttpClient ()) {
			var req = new HttpRequestMessage (HttpMethod.Head, url);
			req.Headers.ConnectionClose = true;

			// Working version: HttpResponseMessage resp = await httpClient.SendAsync (req, HttpCompletionOption.ResponseHeadersRead).ConfigureAwait (true);
			HttpResponseMessage resp = await httpClient.SendAsync (req).ConfigureAwait (true);
			if (!resp.IsSuccessStatusCode || !resp.Content.Headers.ContentLength.HasValue)
				return (false, 0, resp.StatusCode);

			return (true, (ulong)resp.Content.Headers.ContentLength.Value, resp.StatusCode);
		}
	}
}

Crash happens on:

  • Mac: Mono JIT compiler version 6.0.0.184 (2019-02/3a8f93b9a47 Thu Apr 18 09:17:09 EDT 2019)
  • Linux: Mono JIT compiler version 6.0.0.190 (tarball Mon Apr 22 23:46:03 UTC 2019)

Works on 5.x, tested with:

  • Mac: Mono JIT compiler version 5.18.1.3 (2018-08/fdb26b0a445 Wed Mar 20 10:02:02 EDT 2019)
@marek-safar

This comment has been minimized.

Copy link
Member

@marek-safar marek-safar commented Apr 25, 2019

@baulig is it regression from corefx import?

@marek-safar

This comment has been minimized.

Copy link
Member

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

@baulig baulig added won't fix and removed regression labels May 30, 2019
@baulig

This comment has been minimized.

Copy link
Member

@baulig baulig commented May 30, 2019

I have investigated this and can confirm it with both .NET Core as well as Mono (we're using the code from CoreFX). However, this is not really a bug - I'd rather say HttpClient is behaving as expected.

What is happening is that the file you're attempting to download is 2167849215 bytes in size - that's slightly over 2 GB. While HttpClient.MaxResponseContentBufferSize is a long, it won't allow you to set it to anything larger than HttpContent.MaxBufferSize (which is const int MaxBufferSize = int.MaxValue).

It also won't make any sense to increase that limit because allocating over 2 GB of memory isn't really such a good idea.

When you pass HttpCompletionOption.ResponseHeadersRead, then it will only read the headers and not buffer the entire response body (like it does when using the default of ResponseContentRead).

@baulig baulig closed this May 30, 2019
@baulig baulig changed the title System.Net.Http.HttpRequestException: Cannot write more bytes to the buffer than the configured maximum buffer size: 2147483647 on HEAD request HttpClient.SendAsync() with > 2 GB response body. May 30, 2019
@baulig

This comment has been minimized.

Copy link
Member

@baulig baulig commented May 30, 2019

Tested with

$ dotnet --version
3.0.100-preview4-010713
@grendello

This comment has been minimized.

Copy link
Member Author

@grendello grendello commented May 31, 2019

@baulig I'm sorry, but I disagree. This is a regression in code that worked, well, forever and there's no reason for it to break. CoreFX has a bug, in that it stores some size in a 32-bit signed integer (if it has to be signed, make it 64-bit at least) - the workaround presented in OP should not be required here. A resource with size > 2048MB on the internet is a VALID resource and a choice of variable size in internal implementation of HTTP client should not prevent such a resource from being queried. Second, there is no buffer involved here as the HEAD request won't return any body - so the error message is incorrect and misleading. However, the biggest issue here is the regression status and this is the reason why I'm going to reopen the issue - please address it with a fix :)

@grendello grendello reopened this May 31, 2019
@grendello grendello added regression and removed won't fix labels May 31, 2019
@steveisok

This comment has been minimized.

Copy link
Contributor

@steveisok steveisok commented May 31, 2019

Thanks @grendello. @baulig, please look this over and if you can fix it, do so. At the very least we should open an issue w/ corefx.

@baulig

This comment has been minimized.

Copy link
Member

@baulig baulig commented May 31, 2019

Well, it looks like there are two issues here - but it either case, we will have to discuss this with the CoreFX folks, so I 'm going to close this again here, investigate and then follow up with the CoreFX team.

One is that I didn't see that you were sending a HEAD request - it looks like CoreFX is still somehow trying to read the request body, which it shouldn't.

The second one is not a bug - it is actually the code protecting you as there is absolutely no reason why one should ever want to allocate a 2 GB buffer in memory. If you absolutely insist on doing that, well, you can easily do so by just setting ResponseHeadersRead and then reading the entire body into your gigantic buffer.

Also, CoreFX does store the size in a 64-bit variable - only the maximum size that can be buffered in memory is set to int.MaxValue, which is a very reasonable thing to do.

@baulig baulig closed this May 31, 2019
@baulig

This comment has been minimized.

Copy link
Member

@baulig baulig commented May 31, 2019

Will link the CoreFX issue here shortly after I'm done investigating.

@grendello

This comment has been minimized.

Copy link
Member Author

@grendello grendello commented May 31, 2019

Well, it looks like there are two issues here - but it either case, we will have to discuss this with the CoreFX folks, so I 'm going to close this again here, investigate and then follow up with the CoreFX team.

One is that I didn't see that you were sending a HEAD request - it looks like CoreFX is still somehow trying to read the request body, which it shouldn't.

The second one is not a bug - it is actually the code protecting you as there is absolutely no reason why one should ever want to allocate a 2 GB buffer in memory. If you absolutely insist on doing that, well, you can easily do so by just setting ResponseHeadersRead and then reading the entire body into your gigantic buffer.

@baulig I insist that the very act of allocating memory for the transfer like this is a bug. I don't want HttpClient to protect me, I want it to do the right thing. And the right thing is to use NetworkStream with the appropriate inner stream - either stream to a temporary file or stream to MemoryStream if the data is small. No need to "protect" anyone, just make a smart choice.

Also, CoreFX does store the size in a 64-bit variable - only the maximum size that can be buffered in memory is set to int.MaxValue, which is a very reasonable thing to do.

I think it's a bad design choice... Nothing should require allocating more memory than the underlying OS transfer buffers.

@baulig

This comment has been minimized.

Copy link
Member

@baulig baulig commented May 31, 2019

Okay, let me rephrase what I said about because I think it was misleading due to me speaking of two separate issues at all.

  1. A fully agree with you that a HEAD request should not allocate any memory at all.
    That's what I'm currently investigating - I haven't filed an upstream issue yet because I believe that I can come up with a PR instead.
  2. Then I was speaking of the general case, where you are sending a GET request to actually download the body.
    Issuing a SendAsync() with GET and the default of HttpCompletionOption.ResponseContentRead tells HttpClient to read the entire request body and to buffer it. However, this should not ever implicitly allocate a gigantic > 2 GB buffer in memory, but should rather throw an exception telling you hey this is too big maybe you want to read it in chunks instead.
    And in general, using HttpCompletionOption.ResponseContentRead on a large resource is a bad idea. You should really ask yourself whether you really need that entire resource buffered in memory and if not use ResponseHeadersRead.
    If you still insist on being able to buffer > 2 GB, then please discuss that with the CoreFX team. All the actual lengths and sizes are already stored in 64-bit variables - but they'd have to increase HttpContent.MaxBufferSize (which is an internal constant).

I hope that explains it better. So to summarize, you should either see an upstream PR shortly (that I will link here) or - should I be unable to fix it myself - an upstream issue with the results of my investigation.

@baulig

This comment has been minimized.

Copy link
Member

@baulig baulig commented Jun 1, 2019

Filed upstream PR: dotnet/corefx#38129.

@marek-safar marek-safar reopened this Jun 3, 2019
@marek-safar

This comment has been minimized.

Copy link
Member

@marek-safar marek-safar commented Jun 3, 2019

Reopened as we still have to pull the PR once accepted

@grendello

This comment has been minimized.

Copy link
Member Author

@grendello grendello commented Jun 3, 2019

Okay, let me rephrase what I said about because I think it was misleading due to me speaking of two separate issues at all.

1. A fully agree with you that a `HEAD` request should not allocate any memory _at all_.
   That's what I'm currently investigating - I haven't filed an upstream issue yet because I believe that I can come up with a PR instead.

2. Then I was speaking of the general case, where you are sending a `GET` request to actually download the body.
   Issuing a `SendAsync()` with `GET` and the default of `HttpCompletionOption.ResponseContentRead` tells `HttpClient` to read the entire request body and to buffer it.   However, this should not ever implicitly allocate a gigantic > 2 GB buffer in memory, but should rather throw an exception telling you hey this is too big maybe you want to read it in chunks instead.
   And in general, using `HttpCompletionOption.ResponseContentRead` on a large resource is a bad idea.  You should really ask yourself whether you really need that entire resource buffered in memory and if not use `ResponseHeadersRead`.
   If you still insist on being able to buffer > 2 GB, then please discuss that with the CoreFX team.  All the actual lengths and sizes are already stored in 64-bit variables - but they'd have to increase `HttpContent.MaxBufferSize` (which is an internal constant).

And this is where we disagree. The HTTP client should never allocate any more (no matter what the request type is) memory than it needs to transfer the resource from the server to the local system. And by "transfer" I don't mean storing in memory, but doing the right thing to get the entire resource from there to here. Nowhere the process requires allocating more than a few KB of memory to transfer the data (I usually use 8-16K) chunks from the server. Then what happens to the chunks depends on the expected size of the resource. There are three strategies here to consider:

  1. Don't download all the data right away, let the HttpClient user get it at their own pace - they will know what to do with it. This means, fill the buffer(s) from the network only when Read is called on the HttpClient data stream, any size the calling party requests.
  2. If the data is small (for an arbitrary definition of "small" - either a predetermined number or a percentage of available free memory) then, by all means, use MemoryStream as a backing store
  3. If the data is big, use a temporary file stream to stash the data and have the HttpClient user load the data from there (i.e. the HttpClient content stream becomes a file stream)

There is really no need to allocate as much memory as the resource size indicates: this is an open gateway to DoS exploits.

And throwing an exception from a library because the size is too big and the library does the wrong thing is really bad - let the calling party decide what to do by using one of the 3 above options on the library side.

I hope that explains it better. So to summarize, you should either see an upstream PR shortly (that I will link here) or - should I be unable to fix it myself - an upstream issue with the results of my investigation.

I understand your point, but my stance hasn't changed :)

@baulig

This comment has been minimized.

Copy link
Member

@baulig baulig commented Jun 5, 2019

The CoreFX team has merged my PR and I just back ported it here: mono/corefx#297.

I have another pending PR for our CoreFX fork, will bump Mono after that one has landed as well.

@baulig

This comment has been minimized.

Copy link
Member

@baulig baulig commented Jun 5, 2019

And this is where we disagree. The HTTP client should never allocate any more (no matter what the request type is) memory than it needs to transfer the resource from the server to the local system. And by "transfer" I don't mean storing in memory, but doing the right thing to get the entire resource from there to here. Nowhere the process requires allocating more than a few KB of memory to transfer the data (I usually use 8-16K) chunks from the server. Then what happens to the chunks depends on the expected size of the resource. There are three strategies here to consider:

That's actually what the code does. But if the response has a Content-Length of over 2 GB - that's the amount of memory it'd attempt to allocate - and rightfully throw.

  1. Don't download all the data right away, let the HttpClient user get it at their own pace - they will know what to do with it. This means, fill the buffer(s) from the network only when Read is called on the HttpClient data stream, any size the calling party requests.
  2. If the data is small (for an arbitrary definition of "small" - either a predetermined number or a percentage of available free memory) then, by all means, use MemoryStream as a backing store
  3. If the data is big, use a temporary file stream to stash the data and have the HttpClient user load the data from there (i.e. the HttpClient content stream becomes a file stream)

This is entirely your choice - the HttpClient implementation can't decide that for you. You either pass HttpCompletionOption.ResponseContentRead to tell it "I want it all" - or you pass ResponseHeadersRead to manually read it yourself at your own pace. And you can then freely decide how you want to do that - whether you store it in a temp file, or process it right away or anything.

There is really no need to allocate as much memory as the resource size indicates: this is an open gateway to DoS exploits.

You get exactly that by using HttpCompletionOption.ResponseHeadersRead. The default value of HttpCompletionOption.ResponseContentRead is simply a convenient option of telling the code to read it all.

If you want the code to behave differently, then we should discuss this with the CoreFX team because it will ultimately be their decision.

baulig added a commit to baulig/mono that referenced this issue Jun 5, 2019
HttpClient.SendAsync() should not attempt to read response body on a HEAD request.

* CoreFX PR dotnet/corefx#38129.

* Backported in mono/corefx#297.

* Fixes mono#14214.
@baulig

This comment has been minimized.

Copy link
Member

@baulig baulig commented Jun 5, 2019

PR is up: #14821. Will back port into 2019-02 shortly.

baulig added a commit to baulig/mono that referenced this issue Jun 5, 2019
HttpClient.SendAsync() should not attempt to read response body on a HEAD request.

* CoreFX PR dotnet/corefx#38129.

* Backported in mono/corefx#297.

* Fixes mono#14214.
baulig added a commit to baulig/mono that referenced this issue Jun 5, 2019
HttpClient.SendAsync() should not attempt to read response body on a HEAD request.

* CoreFX PR dotnet/corefx#38129.

* Backported in mono/corefx#297.

* Fixes mono#14214.
steveisok added a commit that referenced this issue Jun 6, 2019
HttpClient.SendAsync() should not attempt to read response body on a HEAD request.

* CoreFX PR dotnet/corefx#38129.

* Backported in mono/corefx#297.

* Fixes #14214.
monojenkins added a commit to monojenkins/mono that referenced this issue Jun 6, 2019
HttpClient.SendAsync() should not attempt to read response body on a HEAD request.

* CoreFX PR dotnet/corefx#38129.

* Backported in mono/corefx#297.

* Fixes mono#14214.
baulig added a commit to baulig/mono that referenced this issue Jun 6, 2019
HttpClient.SendAsync() should not attempt to read response body on a HEAD request.

* CoreFX PR dotnet/corefx#38129.

* Backported in mono/corefx#297.

* Fixes mono#14214.

(cherry picked from commit 2b3a23c)
marek-safar added a commit that referenced this issue Jun 6, 2019
HttpClient.SendAsync() should not attempt to read response body on a HEAD request.

* CoreFX PR dotnet/corefx#38129.

* Backported in mono/corefx#297.

* Fixes #14214.

(cherry picked from commit 2b3a23c)
marek-safar added a commit that referenced this issue Jun 6, 2019
HttpClient.SendAsync() should not attempt to read response body on a HEAD request.

* CoreFX PR dotnet/corefx#38129.

* Backported in mono/corefx#297.

* Fixes #14214.
jonpryor added a commit to jonpryor/xamarin-android that referenced this issue Jun 6, 2019
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Jun 6, 2019
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Jun 6, 2019
@grendello

This comment has been minimized.

Copy link
Member Author

@grendello grendello commented Jun 7, 2019

And this is where we disagree. The HTTP client should never allocate any more (no matter what the request type is) memory than it needs to transfer the resource from the server to the local system. And by "transfer" I don't mean storing in memory, but doing the right thing to get the entire resource from there to here. Nowhere the process requires allocating more than a few KB of memory to transfer the data (I usually use 8-16K) chunks from the server. Then what happens to the chunks depends on the expected size of the resource. There are three strategies here to consider:

That's actually what the code does. But if the response has a Content-Length of over 2 GB - that's the amount of memory it'd attempt to allocate - and rightfully throw.

Then it's not what the code does. There's no reason to allocate more than the few K of memory for transfer - let alone 2GB. This is a real bug - how are you supposed to download a 4GB file? How will you download a 2GB-1B file on a machine that has 1GB of RAM? Please fix this properly.

  1. Don't download all the data right away, let the HttpClient user get it at their own pace - they will know what to do with it. This means, fill the buffer(s) from the network only when Read is called on the HttpClient data stream, any size the calling party requests.
  2. If the data is small (for an arbitrary definition of "small" - either a predetermined number or a percentage of available free memory) then, by all means, use MemoryStream as a backing store
  3. If the data is big, use a temporary file stream to stash the data and have the HttpClient user load the data from there (i.e. the HttpClient content stream becomes a file stream)

This is entirely your choice - the HttpClient implementation can't decide that for you. You either pass HttpCompletionOption.ResponseContentRead to tell it "I want it all" - or you pass ResponseHeadersRead to manually read it yourself at your own pace. And you can then freely decide how you want to do that - whether you store it in a temp file, or process it right away or anything.

I have NO choice here, that's the point! If the content-length indicates > 2GB I have no say, unless I use the HttpCompletionOption flag above - but there is NO REASON for me to have to use it. This behavior is absolutely wrong.

There is really no need to allocate as much memory as the resource size indicates: this is an open gateway to DoS exploits.

You get exactly that by using HttpCompletionOption.ResponseHeadersRead. The default value of HttpCompletionOption.ResponseContentRead is simply a convenient option of telling the code to read it all.

If you want the code to behave differently, then we should discuss this with the CoreFX team because it will ultimately be their decision.

@grendello

This comment has been minimized.

Copy link
Member Author

@grendello grendello commented Jun 7, 2019

To point out further problems with "allocate all the RAM unless it's less than 2GB" of the default HttpClient behavior (without HttpCompletionOption.ResponseContentRead explicitly set):

  • in order to avoid the exception, you either have to set HttpCompletionOption.ResponseContentRead or always issue a HEAD request and set this flag when resource size is bigger than some sane amount - to prevent HttpClient from DoS-ing your machine by allocating too much memory
  • what happens if your app runs on a machine with 1GB of RAM and you did NOT set HttpCompletionOption.ResponseContentRead? The app, and likely the machine, dies - or goes to a crawl constantly swapping memory in and out. Probably crashes, though.
  • what happens if your machine has 8GB of RAM and you launch 5 threads to download 1.8GB files each? Default HttpClient will happily allocate all that RAM, creating the same problem as in the bullet point above

As it currently stands, the default HttpClient behavior is unreliable and unsuitable for any real world scenario - unless your app tightly controls the size of the resources it downloads and proactively prevents HttpClient from working in its default way. I will stress it once again: there is no reason to allocate a transfer buffer that matches the size of the resource being downloaded It's dangerous, it's wasteful, it's not needed for the client to work properly.

@grendello

This comment has been minimized.

Copy link
Member Author

@grendello grendello commented Jun 7, 2019

@baulig please address the allocation issue, it's really not the way it should be. Considering that the HEAD part of it was fixed, I've removed the regression label.

@grendello grendello reopened this Jun 7, 2019
@grendello grendello removed the regression label Jun 7, 2019
@baulig baulig closed this Jun 7, 2019
@steveisok

This comment has been minimized.

Copy link
Contributor

@steveisok steveisok commented Jun 7, 2019

@grendello, I appreciate your passion re: this issue. I think it does have merit and probably warrants a discussion upstream w/ the corefx team. I'm open to suggestions and we would be happy to help you.

Would it make sense for you to open an issue w/ corefx and summarize? Or should we open an issue and link to this one? Again, I'm open to suggestions.

@baulig

This comment has been minimized.

Copy link
Member

@baulig baulig commented Jun 7, 2019

Okay, we have a few issues and concerns here. My biggest one of those is that your last comment makes me unable to upstream this to corefx as I feel like it is insulting and inflammatory of their work - and I also strongly disagree with the assessment that their code is "unreliable and unsuitable for any real world scenario". I have no intention of creating any kind of conflict with the CoreFX team, so you're essentially pushing me out of this.

Secondly, I feel a bit like you either did not read or did not properly understand what I said before, considering that your list above is factually incorrect when it comes to the HttpCompletionOption, which you got upside-down.

So let me try this again one last time - and then I'll close this for good.

You as the user have two choices

  • Either you tell HttpClient to read the entire response body. This is done by using HttpCompletionOption.ResponseContentRead. In this case it will allocate as much memory is needed to buffer it. The returned HttpContent will then contain an in-memory buffered representation.

or

  • You tell HttpClient to only read the response headers. This is done by using HttpCompletionOption.ResponseHeadersRead and you will get a stream-based HttpContent. Then you can read that stream-based HttpContent in any way you choose. This has absolutely nothing to do with doing a HEAD request, it will work perfectly fine for any request; GET, POST, whatever.

There is no way the HttpClient implementation can do that choice for you.

If you disagree with this, then please discuss it with the CoreFX team.

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
4 participants
You can’t perform that action at this time.