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

Memory leak in mono 6.0.0.313 for delegates with target that are passed to native code #15751

Closed
MattL0 opened this issue Jul 18, 2019 · 17 comments · Fixed by #15935 or xamarin/xamarin-android#3443
Assignees

Comments

@MattL0
Copy link

@MattL0 MattL0 commented Jul 18, 2019

Hi,

I have tested the 6.x.x.x preview a couple of time. ( first time at 6.0.0.171, and there was already this memory leak!)

I know 5.0.1.34 has been a ''nightmare', and you have my empathy ! I believe you had to push this version as the stable one, under the circumstances

But here , i use mono to run Homeseer. So Homeseer is completely dependent of mono to run.

Before 6.x.x.x the HOMESEER process was not eating memory like this before.
after 1 hour , it was more like 130-140 mo. And could eat 250-275 mo after 1.5-2 days. There was already a small leak on mono 5.x.x.x (70-80mb/day), but it was nothing compared to now.

I did run my install of HomeSeer on windows for testing , and there is no memory leak at all. Homeseer officially support Linux via mono

So, now it ( the memory) just keep raising, How can i track this down?

Thanks
Capture

@MattL0

This comment has been minimized.

Copy link
Author

@MattL0 MattL0 commented Jul 18, 2019

Capture

@MattL0 MattL0 changed the title memory leak in mono 6.0..0313 Memory leak in mono 6.0.0.313 (big one) Jul 19, 2019
@MattL0 MattL0 changed the title Memory leak in mono 6.0.0.313 (big one) Memory leak in mono 6.0.0.313 -Big one- Jul 19, 2019
@MattL0 MattL0 changed the title Memory leak in mono 6.0.0.313 -Big one- Memory leak in mono 6.0.0.313 (Big one). Jul 19, 2019
@MattL0

This comment has been minimized.

Copy link
Author

@MattL0 MattL0 commented Jul 19, 2019

Capture

I am sending every 20 mins via mqtt, HOMESEER memory usage to Nodered dashboard ui.

mono

@MattL0

This comment has been minimized.

Copy link
Author

@MattL0 MattL0 commented Jul 19, 2019

Here I have downgraded to the VS build mono 5.18.1.28.

will post again tomorrow . I need to restart the pc now... But will let it run for the night
Capture

@MattL0

This comment has been minimized.

Copy link
Author

@MattL0 MattL0 commented Jul 19, 2019

Capture

as you can see, there seems to be a memory leak on 5.18.1.28, but not as big as on mono 6.0.0.313

@MattL0

This comment has been minimized.

Copy link
Author

@MattL0 MattL0 commented Jul 22, 2019

Anyone? there must have been a change in mono 6 x.x.x.x concerning memory? This is with the exact same setup. If I know what changed, maybe i can transfer the info the the Homeseer plugin developer... and then..they can adapt with the new requirement of mono 6.0? thanks

@marek-safar

This comment has been minimized.

Copy link
Member

@marek-safar marek-safar commented Jul 22, 2019

There has been a lot of changes for that reason it's not trivial to confirm this. Could you share with some any repro we could use to see the memory leak?

@MattL0

This comment has been minimized.

Copy link
Author

@MattL0 MattL0 commented Jul 25, 2019

Hi @marek-safar , I have prepared a Virtual machine for your with vm ware.

Installed mono 6.0.0.313.

Loaded my config on it but removed as much as i can my personal info. I have loaded a 30 days trial with it.

  1. Run it on vmware ( you can acess via ssh)

  2. username : root

  3. password : 1234567

  4. cd /HomeSeer

  5. then run ./HSConsole.exe --log ( if you close this homeseer will close ( you can add a systemd service, but you won't see the detailed log like that )

  6. to access the web interface go to your navigator : Machine_ip:88

Do you have an email I can send the link to ?

@MattL0

This comment has been minimized.

Copy link
Author

@MattL0 MattL0 commented Jul 25, 2019

The link is now ready. I just uploaded it. Just need an email address to sent it to you.

@BrzVlad

This comment has been minimized.

Copy link
Member

@BrzVlad BrzVlad commented Jul 27, 2019

@MattL0 I could take a look at this. vlbrez@microsoft.com

@MattL0

This comment has been minimized.

Copy link
Author

@MattL0 MattL0 commented Jul 27, 2019

Thanks @BrzVlad Sent you the link via email .

@BrzVlad BrzVlad self-assigned this Jul 29, 2019
BrzVlad added a commit to BrzVlad/mono that referenced this issue Jul 31, 2019
For static method delegates, we have a unique delegate_trampoline that is shared among all delegates. We always keep alive the first static method delegate passed to native, by creating a normal gchandle to it and storing it in delegate_hash_table. For instance methods, each delegate will create a separate wrapper and these wrappers are never shared (which was wrongly assumed in mono@caa4a75). We shuldn't keep the delegate alive and this commit reverts the behavior for delegate with instance methods introduced in the mentioned commit.

Fixes mono#15751
BrzVlad added a commit to BrzVlad/mono that referenced this issue Jul 31, 2019
For static method delegates, we have a unique delegate_trampoline that is shared among all delegates. We always keep alive the first static method delegate passed to native, by creating a normal gchandle to it and storing it in delegate_hash_table. For instance methods, each delegate will create a separate wrapper and these wrappers are never shared (which was wrongly assumed in mono@caa4a75). We shuldn't keep the delegate alive and this commit reverts the behavior for delegate with instance methods introduced in the mentioned commit.

Fixes mono#15751
@marek-safar marek-safar added this to the 2019-02 (6.0.xx) milestone Aug 1, 2019
BrzVlad added a commit that referenced this issue Aug 1, 2019
…15935)

* [marshal] Always use gchandles in delegate_hash_table

Makes the code easier to follow and it also fixes race from caa4a75 with boehm.

* [marshal] Free delegates with target that are passed to native code.

For static method delegates, we have a unique delegate_trampoline that is shared among all delegates. We always keep alive the first static method delegate passed to native, by creating a normal gchandle to it and storing it in delegate_hash_table. For instance methods, each delegate will create a separate wrapper and these wrappers are never shared (which was wrongly assumed in caa4a75). We shuldn't keep the delegate alive and this commit reverts the behavior for delegate with instance methods introduced in the mentioned commit.

Fixes #15751
monojenkins added a commit to monojenkins/mono that referenced this issue Aug 1, 2019
For static method delegates, we have a unique delegate_trampoline that is shared among all delegates. We always keep alive the first static method delegate passed to native, by creating a normal gchandle to it and storing it in delegate_hash_table. For instance methods, each delegate will create a separate wrapper and these wrappers are never shared (which was wrongly assumed in mono@caa4a75). We shuldn't keep the delegate alive and this commit reverts the behavior for delegate with instance methods introduced in the mentioned commit.

Fixes mono#15751
akoeplinger added a commit that referenced this issue Aug 1, 2019
…ive code. (#15966)

* [marshal] Always use gchandles in delegate_hash_table

Makes the code easier to follow and it also fixes race from caa4a75 with boehm.

* [marshal] Free delegates with target that are passed to native code.

For static method delegates, we have a unique delegate_trampoline that is shared among all delegates. We always keep alive the first static method delegate passed to native, by creating a normal gchandle to it and storing it in delegate_hash_table. For instance methods, each delegate will create a separate wrapper and these wrappers are never shared (which was wrongly assumed in caa4a75). We shuldn't keep the delegate alive and this commit reverts the behavior for delegate with instance methods introduced in the mentioned commit.

Fixes #15751

Backport of #15935.
imhameed added a commit to imhameed/mono that referenced this issue Aug 2, 2019
…ono#15935)

* [marshal] Always use gchandles in delegate_hash_table

Makes the code easier to follow and it also fixes race from mono@caa4a75 with boehm.

* [marshal] Free delegates with target that are passed to native code.

For static method delegates, we have a unique delegate_trampoline that is shared among all delegates. We always keep alive the first static method delegate passed to native, by creating a normal gchandle to it and storing it in delegate_hash_table. For instance methods, each delegate will create a separate wrapper and these wrappers are never shared (which was wrongly assumed in mono@caa4a75). We shuldn't keep the delegate alive and this commit reverts the behavior for delegate with instance methods introduced in the mentioned commit.

Fixes mono#15751
@marek-safar marek-safar changed the title Memory leak in mono 6.0.0.313 (Big one). Memory leak in mono 6.0.0.313 for delegates with target that are passed to native code Aug 5, 2019
monojenkins added a commit to monojenkins/mono that referenced this issue Aug 5, 2019
For static method delegates, we have a unique delegate_trampoline that is shared among all delegates. We always keep alive the first static method delegate passed to native, by creating a normal gchandle to it and storing it in delegate_hash_table. For instance methods, each delegate will create a separate wrapper and these wrappers are never shared (which was wrongly assumed in mono@caa4a75). We shuldn't keep the delegate alive and this commit reverts the behavior for delegate with instance methods introduced in the mentioned commit.

Fixes mono#15751
marek-safar added a commit that referenced this issue Aug 5, 2019
* [marshal] Always use gchandles in delegate_hash_table

Makes the code easier to follow and it also fixes race from caa4a75 with boehm.

* [marshal] Free delegates with target that are passed to native code.

For static method delegates, we have a unique delegate_trampoline that is shared among all delegates. We always keep alive the first static method delegate passed to native, by creating a normal gchandle to it and storing it in delegate_hash_table. For instance methods, each delegate will create a separate wrapper and these wrappers are never shared (which was wrongly assumed in caa4a75). We shuldn't keep the delegate alive and this commit reverts the behavior for delegate with instance methods introduced in the mentioned commit.

Fixes #15751
jonpryor added a commit to jonpryor/xamarin-android that referenced this issue Aug 5, 2019
Changes: mono/mono@761220d...6fbdb37

Fixes: mono/mono#15751
Fixes: mono/mono#15825
Fixes: mono/mono#15878
Fixes: mono/mono#15887

Fix `Socket.ConnectAsync(SocketAsyncEventArgs)` behavior
imhameed added a commit to imhameed/mono that referenced this issue Aug 7, 2019
…ono#15935)

* [marshal] Always use gchandles in delegate_hash_table

Makes the code easier to follow and it also fixes race from mono@caa4a75 with boehm.

* [marshal] Free delegates with target that are passed to native code.

For static method delegates, we have a unique delegate_trampoline that is shared among all delegates. We always keep alive the first static method delegate passed to native, by creating a normal gchandle to it and storing it in delegate_hash_table. For instance methods, each delegate will create a separate wrapper and these wrappers are never shared (which was wrongly assumed in mono@caa4a75). We shuldn't keep the delegate alive and this commit reverts the behavior for delegate with instance methods introduced in the mentioned commit.

Fixes mono#15751
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Aug 9, 2019
Fixes: mono/mono#15261
Fixes: mono/mono#15262
Fixes: mono/mono#15263
Fixes: mono/mono#15307
Fixes: mono/mono#15751
Fixes: mono/mono#15825
Fixes: mono/mono#15878
Fixes: mono/mono#15887

[w32socket] Translate ELOOP and ENAMETOOLONG

[corlib] Ignore TimeZoneTest.TestCtors on Android GMT
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Aug 10, 2019
Context: mono/mono#9621
Context: http://build.azdo.io/2927809

Fixes: mono/mono#15261
Fixes: mono/mono#15262
Fixes: mono/mono#15263
Fixes: mono/mono#15307
Fixes: mono/mono#15751
Fixes: mono/mono#15825
Fixes: mono/mono#15878
Fixes: mono/mono#15887

[w32socket] Translate ELOOP and ENAMETOOLONG

[corlib] Ignore TimeZoneTest.TestCtors on Android GMT

Additionally, mono cross compilers are now always 64-bit, as are the
LLVM runtimes.  64-bit cross-compilers broke the xamarin-android
build, as it was using a 32-bit `strip` on them, which failed.

Use the correct `strip` utility, and remove the reference to a
Windows 32bit LLVM runtime which no longer exists.

The mono archive also no longer contains any `llvmwin32` content,
so ensure that the correct LLVM runtimes are installed.
@MattL0

This comment has been minimized.

Copy link
Author

@MattL0 MattL0 commented Aug 10, 2019

Hi thanks a lot for this !

Please see the hsconsole.exe memory consumption .

  1. ( 4 hours runtime and 232m)
    I have tested mono 6.0.0.319 binary ( precompiled with llvm I think) and it still leaks.
    htop

  2. (18 hours runtime and 156m)
    I have compiled mono 6.7 ( without llvm compilation since i was not able to use it see : #16099) yesterday and it does not leak. I think it is leaking but way less. This is something that was present in mono 5.x.x.x.

htop2

Mono JIT compiler version 6.7.0 (master/b52830cf112 Fri 09 Aug 2019 04:58:30 PM EDT)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
Interpreter: yes
LLVM: supported, not enabled.
Suspend: hybrid
GC: sgen (concurrent by default)

Would it be possible to test the Virtual machine again?

thanks.

@MattL0

This comment has been minimized.

Copy link
Author

@MattL0 MattL0 commented Aug 10, 2019

@MattL0

This comment has been minimized.

Copy link
Author

@MattL0 MattL0 commented Aug 12, 2019

@marek-safar @BrzVlad please reopen.

Thanks

@BrzVlad BrzVlad reopened this Aug 12, 2019
@AllHailJ

This comment has been minimized.

Copy link

@AllHailJ AllHailJ commented Aug 14, 2019

While @ MattL0 is moving I am watching. the 6.7.0.99 nightly build worked nearly perfect. I upgrade to .105 and the nightly build was not allowing the z-wave module to function (could not turn on/off devices).

@MattL0

This comment has been minimized.

Copy link
Author

@MattL0 MattL0 commented Aug 14, 2019

Why is this issue closed ? Thanks

@BrzVlad BrzVlad reopened this Aug 15, 2019
@BrzVlad BrzVlad reopened this Aug 29, 2019
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Sep 4, 2019
Changes: mono/mono@e6f5369...6256b82

Upstream-Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/976811
Upstream-Fixes: mono/mono#15751
Upstream-Fixes: mono/mono#15825
Upstream-Fixes: mono/mono#16032
Upstream-Fixes: mono/mono#16122
Upstream-Fixes: mono/mono#16486
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Sep 4, 2019
Changes: mono/mono@e6f5369...6256b82

Upstream-Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/976811
Upstream-Fixes: mono/mono#15751
Upstream-Fixes: mono/mono#15825
Upstream-Fixes: mono/mono#16032
Upstream-Fixes: mono/mono#16122
Upstream-Fixes: mono/mono#16486
@lewurm lewurm reopened this Sep 6, 2019
@BrzVlad

This comment has been minimized.

Copy link
Member

@BrzVlad BrzVlad commented Sep 6, 2019

I ran the repro for almost two days and I didn't see any unreasonable increases in memory consumption / leaks.

The small leak is fixed by e49be5b

@BrzVlad BrzVlad closed this Sep 6, 2019
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.
@MattL0

This comment has been minimized.

Copy link
Author

@MattL0 MattL0 commented Sep 6, 2019

Thanks @BrzVlad

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