Fix locking around m_LoaderAllocatorReferences iteration by janvorli · Pull Request #68336 · dotnet/runtime

janvorli · 2022-04-21T16:20:51Z

The iteration that marks loader allocators in LoaderAllocator::Mark()
was not being called under an appropriate lock, which lead to a rare and
hard to reproduce race condition and a crash in the
LoaderAllocator::Mark(). The issue happened when the
m_LoaderAllocatorReferences.Begin() returned an iterator at the time the
m_LoaderAllocatorReferences were empty and another thread has written
something into those references before the
m_LoaderAllocatorReferences.End() was called. The iter was then
evaluated as not equal to the End and the iter was getting dereferenced.
Since the iterator had m_table set to NULL, the dereferencing caused
crash.

The issue shows up as something like this:

Fatal error. Internal CLR error. (0x80131506)
at System.Reflection.LoaderAllocatorScout.<Destroy>g____PInvoke__|1_0(IntPtr)
at System.Reflection.LoaderAllocatorScout.Finalize()

The iteration that marks loader allocators in LoaderAllocator::Mark() was not being called under an appropriate lock, which lead to a rare and hard to reproduce race condition and a crash in the LoaderAllocator::Mark(). The issue happened when the m_LoaderAllocatorReferences.Begin() returned an iterator at the time the m_LoaderAllocatorReferences were empty and another thread has written something into those references before the m_LoaderAllocatorReferences.End() was called. The iter was then evaluated as not equal to the End and the iter was getting dereferenced. Since the iterator had m_table set to NULL, the dereferencing caused crash.

jkotas · 2022-04-21T16:55:22Z

 // Iterate through every loader allocator, marking as we go
 {
+ CrstHolder chLoaderAllocatorReferencesLock(pAppDomain->GetLoaderAllocatorReferencesLock());
 CrstHolder chAssemblyListLock(pAppDomain->GetAssemblyListLock());


The second iteration below is going to acquire same locks now. We can acquire the locks just once for the whole duration of both iterations.

Makes sense, I'll update the PR that way.

teo-tsirpanis · 2022-04-21T19:26:11Z

(setting the milestone to 7.0.0; the PR targets main, 6.0.x is for backports)

This change ports two unloadability fixes for issues found by a customer. * dotnet#68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * dotnet#68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction.

* [Release/6.0] Port unloadability fixes This change ports two unloadability fixes for issues found by a customer. * #68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * #68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction. * Remove breaking change part The change in main has added an exception in case a collectible `Assembly` is resolved into a non-collectible `AssemblyLoadContext`. Although that is incorrect, there are cases when it would work. So the added exception is a breaking change that I think we likely don't want to get into 6.0

janvorli · 2022-04-21T16:20:51Z

The iteration that marks loader allocators in LoaderAllocator::Mark()
was not being called under an appropriate lock, which lead to a rare and
hard to reproduce race condition and a crash in the
LoaderAllocator::Mark(). The issue happened when the
m_LoaderAllocatorReferences.Begin() returned an iterator at the time the
m_LoaderAllocatorReferences were empty and another thread has written
something into those references before the
m_LoaderAllocatorReferences.End() was called. The iter was then
evaluated as not equal to the End and the iter was getting dereferenced.
Since the iterator had m_table set to NULL, the dereferencing caused
crash.

The issue shows up as something like this:

Fatal error. Internal CLR error. (0x80131506)
at System.Reflection.LoaderAllocatorScout.<Destroy>g____PInvoke__|1_0(IntPtr)
at System.Reflection.LoaderAllocatorScout.Finalize()

The iteration that marks loader allocators in LoaderAllocator::Mark() was not being called under an appropriate lock, which lead to a rare and hard to reproduce race condition and a crash in the LoaderAllocator::Mark(). The issue happened when the m_LoaderAllocatorReferences.Begin() returned an iterator at the time the m_LoaderAllocatorReferences were empty and another thread has written something into those references before the m_LoaderAllocatorReferences.End() was called. The iter was then evaluated as not equal to the End and the iter was getting dereferenced. Since the iterator had m_table set to NULL, the dereferencing caused crash.

jkotas · 2022-04-21T16:55:22Z

 // Iterate through every loader allocator, marking as we go
 {
+ CrstHolder chLoaderAllocatorReferencesLock(pAppDomain->GetLoaderAllocatorReferencesLock());
 CrstHolder chAssemblyListLock(pAppDomain->GetAssemblyListLock());


The second iteration below is going to acquire same locks now. We can acquire the locks just once for the whole duration of both iterations.

Makes sense, I'll update the PR that way.

teo-tsirpanis · 2022-04-21T19:26:11Z

(setting the milestone to 7.0.0; the PR targets main, 6.0.x is for backports)

This change ports two unloadability fixes for issues found by a customer. * dotnet#68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * dotnet#68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction.

* [Release/6.0] Port unloadability fixes This change ports two unloadability fixes for issues found by a customer. * #68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * #68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction. * Remove breaking change part The change in main has added an exception in case a collectible `Assembly` is resolved into a non-collectible `AssemblyLoadContext`. Although that is incorrect, there are cases when it would work. So the added exception is a breaking change that I think we likely don't want to get into 6.0

janvorli · 2022-04-21T16:20:51Z

The iteration that marks loader allocators in LoaderAllocator::Mark()
was not being called under an appropriate lock, which lead to a rare and
hard to reproduce race condition and a crash in the
LoaderAllocator::Mark(). The issue happened when the
m_LoaderAllocatorReferences.Begin() returned an iterator at the time the
m_LoaderAllocatorReferences were empty and another thread has written
something into those references before the
m_LoaderAllocatorReferences.End() was called. The iter was then
evaluated as not equal to the End and the iter was getting dereferenced.
Since the iterator had m_table set to NULL, the dereferencing caused
crash.

The issue shows up as something like this:

Fatal error. Internal CLR error. (0x80131506)
at System.Reflection.LoaderAllocatorScout.<Destroy>g____PInvoke__|1_0(IntPtr)
at System.Reflection.LoaderAllocatorScout.Finalize()

The iteration that marks loader allocators in LoaderAllocator::Mark() was not being called under an appropriate lock, which lead to a rare and hard to reproduce race condition and a crash in the LoaderAllocator::Mark(). The issue happened when the m_LoaderAllocatorReferences.Begin() returned an iterator at the time the m_LoaderAllocatorReferences were empty and another thread has written something into those references before the m_LoaderAllocatorReferences.End() was called. The iter was then evaluated as not equal to the End and the iter was getting dereferenced. Since the iterator had m_table set to NULL, the dereferencing caused crash.

jkotas · 2022-04-21T16:55:22Z

 // Iterate through every loader allocator, marking as we go
 {
+ CrstHolder chLoaderAllocatorReferencesLock(pAppDomain->GetLoaderAllocatorReferencesLock());
 CrstHolder chAssemblyListLock(pAppDomain->GetAssemblyListLock());


The second iteration below is going to acquire same locks now. We can acquire the locks just once for the whole duration of both iterations.

Makes sense, I'll update the PR that way.

teo-tsirpanis · 2022-04-21T19:26:11Z

(setting the milestone to 7.0.0; the PR targets main, 6.0.x is for backports)

This change ports two unloadability fixes for issues found by a customer. * dotnet#68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * dotnet#68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction.

* [Release/6.0] Port unloadability fixes This change ports two unloadability fixes for issues found by a customer. * #68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * #68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction. * Remove breaking change part The change in main has added an exception in case a collectible `Assembly` is resolved into a non-collectible `AssemblyLoadContext`. Although that is incorrect, there are cases when it would work. So the added exception is a breaking change that I think we likely don't want to get into 6.0

janvorli · 2022-04-21T16:20:51Z

The iteration that marks loader allocators in LoaderAllocator::Mark()
was not being called under an appropriate lock, which lead to a rare and
hard to reproduce race condition and a crash in the
LoaderAllocator::Mark(). The issue happened when the
m_LoaderAllocatorReferences.Begin() returned an iterator at the time the
m_LoaderAllocatorReferences were empty and another thread has written
something into those references before the
m_LoaderAllocatorReferences.End() was called. The iter was then
evaluated as not equal to the End and the iter was getting dereferenced.
Since the iterator had m_table set to NULL, the dereferencing caused
crash.

The issue shows up as something like this:

Fatal error. Internal CLR error. (0x80131506)
at System.Reflection.LoaderAllocatorScout.<Destroy>g____PInvoke__|1_0(IntPtr)
at System.Reflection.LoaderAllocatorScout.Finalize()

The iteration that marks loader allocators in LoaderAllocator::Mark() was not being called under an appropriate lock, which lead to a rare and hard to reproduce race condition and a crash in the LoaderAllocator::Mark(). The issue happened when the m_LoaderAllocatorReferences.Begin() returned an iterator at the time the m_LoaderAllocatorReferences were empty and another thread has written something into those references before the m_LoaderAllocatorReferences.End() was called. The iter was then evaluated as not equal to the End and the iter was getting dereferenced. Since the iterator had m_table set to NULL, the dereferencing caused crash.

jkotas · 2022-04-21T16:55:22Z

 // Iterate through every loader allocator, marking as we go
 {
+ CrstHolder chLoaderAllocatorReferencesLock(pAppDomain->GetLoaderAllocatorReferencesLock());
 CrstHolder chAssemblyListLock(pAppDomain->GetAssemblyListLock());


The second iteration below is going to acquire same locks now. We can acquire the locks just once for the whole duration of both iterations.

Makes sense, I'll update the PR that way.

teo-tsirpanis · 2022-04-21T19:26:11Z

(setting the milestone to 7.0.0; the PR targets main, 6.0.x is for backports)

This change ports two unloadability fixes for issues found by a customer. * dotnet#68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * dotnet#68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction.

* [Release/6.0] Port unloadability fixes This change ports two unloadability fixes for issues found by a customer. * #68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * #68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction. * Remove breaking change part The change in main has added an exception in case a collectible `Assembly` is resolved into a non-collectible `AssemblyLoadContext`. Although that is incorrect, there are cases when it would work. So the added exception is a breaking change that I think we likely don't want to get into 6.0

janvorli · 2022-04-21T16:20:51Z

The iteration that marks loader allocators in LoaderAllocator::Mark()
was not being called under an appropriate lock, which lead to a rare and
hard to reproduce race condition and a crash in the
LoaderAllocator::Mark(). The issue happened when the
m_LoaderAllocatorReferences.Begin() returned an iterator at the time the
m_LoaderAllocatorReferences were empty and another thread has written
something into those references before the
m_LoaderAllocatorReferences.End() was called. The iter was then
evaluated as not equal to the End and the iter was getting dereferenced.
Since the iterator had m_table set to NULL, the dereferencing caused
crash.

The issue shows up as something like this:

Fatal error. Internal CLR error. (0x80131506)
at System.Reflection.LoaderAllocatorScout.<Destroy>g____PInvoke__|1_0(IntPtr)
at System.Reflection.LoaderAllocatorScout.Finalize()

The iteration that marks loader allocators in LoaderAllocator::Mark() was not being called under an appropriate lock, which lead to a rare and hard to reproduce race condition and a crash in the LoaderAllocator::Mark(). The issue happened when the m_LoaderAllocatorReferences.Begin() returned an iterator at the time the m_LoaderAllocatorReferences were empty and another thread has written something into those references before the m_LoaderAllocatorReferences.End() was called. The iter was then evaluated as not equal to the End and the iter was getting dereferenced. Since the iterator had m_table set to NULL, the dereferencing caused crash.

jkotas · 2022-04-21T16:55:22Z

 // Iterate through every loader allocator, marking as we go
 {
+ CrstHolder chLoaderAllocatorReferencesLock(pAppDomain->GetLoaderAllocatorReferencesLock());
 CrstHolder chAssemblyListLock(pAppDomain->GetAssemblyListLock());


The second iteration below is going to acquire same locks now. We can acquire the locks just once for the whole duration of both iterations.

Makes sense, I'll update the PR that way.

teo-tsirpanis · 2022-04-21T19:26:11Z

(setting the milestone to 7.0.0; the PR targets main, 6.0.x is for backports)

This change ports two unloadability fixes for issues found by a customer. * dotnet#68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * dotnet#68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction.

* [Release/6.0] Port unloadability fixes This change ports two unloadability fixes for issues found by a customer. * #68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * #68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction. * Remove breaking change part The change in main has added an exception in case a collectible `Assembly` is resolved into a non-collectible `AssemblyLoadContext`. Although that is incorrect, there are cases when it would work. So the added exception is a breaking change that I think we likely don't want to get into 6.0

janvorli · 2022-04-21T16:20:51Z

The iteration that marks loader allocators in LoaderAllocator::Mark()
was not being called under an appropriate lock, which lead to a rare and
hard to reproduce race condition and a crash in the
LoaderAllocator::Mark(). The issue happened when the
m_LoaderAllocatorReferences.Begin() returned an iterator at the time the
m_LoaderAllocatorReferences were empty and another thread has written
something into those references before the
m_LoaderAllocatorReferences.End() was called. The iter was then
evaluated as not equal to the End and the iter was getting dereferenced.
Since the iterator had m_table set to NULL, the dereferencing caused
crash.

The issue shows up as something like this:

Fatal error. Internal CLR error. (0x80131506)
at System.Reflection.LoaderAllocatorScout.<Destroy>g____PInvoke__|1_0(IntPtr)
at System.Reflection.LoaderAllocatorScout.Finalize()

The iteration that marks loader allocators in LoaderAllocator::Mark() was not being called under an appropriate lock, which lead to a rare and hard to reproduce race condition and a crash in the LoaderAllocator::Mark(). The issue happened when the m_LoaderAllocatorReferences.Begin() returned an iterator at the time the m_LoaderAllocatorReferences were empty and another thread has written something into those references before the m_LoaderAllocatorReferences.End() was called. The iter was then evaluated as not equal to the End and the iter was getting dereferenced. Since the iterator had m_table set to NULL, the dereferencing caused crash.

jkotas · 2022-04-21T16:55:22Z

 // Iterate through every loader allocator, marking as we go
 {
+ CrstHolder chLoaderAllocatorReferencesLock(pAppDomain->GetLoaderAllocatorReferencesLock());
 CrstHolder chAssemblyListLock(pAppDomain->GetAssemblyListLock());


The second iteration below is going to acquire same locks now. We can acquire the locks just once for the whole duration of both iterations.

Makes sense, I'll update the PR that way.

teo-tsirpanis · 2022-04-21T19:26:11Z

(setting the milestone to 7.0.0; the PR targets main, 6.0.x is for backports)

This change ports two unloadability fixes for issues found by a customer. * dotnet#68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * dotnet#68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction.

* [Release/6.0] Port unloadability fixes This change ports two unloadability fixes for issues found by a customer. * #68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * #68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction. * Remove breaking change part The change in main has added an exception in case a collectible `Assembly` is resolved into a non-collectible `AssemblyLoadContext`. Although that is incorrect, there are cases when it would work. So the added exception is a breaking change that I think we likely don't want to get into 6.0

janvorli · 2022-04-21T16:20:51Z

The iteration that marks loader allocators in LoaderAllocator::Mark()
was not being called under an appropriate lock, which lead to a rare and
hard to reproduce race condition and a crash in the
LoaderAllocator::Mark(). The issue happened when the
m_LoaderAllocatorReferences.Begin() returned an iterator at the time the
m_LoaderAllocatorReferences were empty and another thread has written
something into those references before the
m_LoaderAllocatorReferences.End() was called. The iter was then
evaluated as not equal to the End and the iter was getting dereferenced.
Since the iterator had m_table set to NULL, the dereferencing caused
crash.

The issue shows up as something like this:

Fatal error. Internal CLR error. (0x80131506)
at System.Reflection.LoaderAllocatorScout.<Destroy>g____PInvoke__|1_0(IntPtr)
at System.Reflection.LoaderAllocatorScout.Finalize()

The iteration that marks loader allocators in LoaderAllocator::Mark() was not being called under an appropriate lock, which lead to a rare and hard to reproduce race condition and a crash in the LoaderAllocator::Mark(). The issue happened when the m_LoaderAllocatorReferences.Begin() returned an iterator at the time the m_LoaderAllocatorReferences were empty and another thread has written something into those references before the m_LoaderAllocatorReferences.End() was called. The iter was then evaluated as not equal to the End and the iter was getting dereferenced. Since the iterator had m_table set to NULL, the dereferencing caused crash.

jkotas · 2022-04-21T16:55:22Z

 // Iterate through every loader allocator, marking as we go
 {
+ CrstHolder chLoaderAllocatorReferencesLock(pAppDomain->GetLoaderAllocatorReferencesLock());
 CrstHolder chAssemblyListLock(pAppDomain->GetAssemblyListLock());


The second iteration below is going to acquire same locks now. We can acquire the locks just once for the whole duration of both iterations.

Makes sense, I'll update the PR that way.

teo-tsirpanis · 2022-04-21T19:26:11Z

(setting the milestone to 7.0.0; the PR targets main, 6.0.x is for backports)

This change ports two unloadability fixes for issues found by a customer. * dotnet#68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * dotnet#68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction.

* [Release/6.0] Port unloadability fixes This change ports two unloadability fixes for issues found by a customer. * #68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * #68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction. * Remove breaking change part The change in main has added an exception in case a collectible `Assembly` is resolved into a non-collectible `AssemblyLoadContext`. Although that is incorrect, there are cases when it would work. So the added exception is a breaking change that I think we likely don't want to get into 6.0

janvorli · 2022-04-21T16:20:51Z

The iteration that marks loader allocators in LoaderAllocator::Mark()
was not being called under an appropriate lock, which lead to a rare and
hard to reproduce race condition and a crash in the
LoaderAllocator::Mark(). The issue happened when the
m_LoaderAllocatorReferences.Begin() returned an iterator at the time the
m_LoaderAllocatorReferences were empty and another thread has written
something into those references before the
m_LoaderAllocatorReferences.End() was called. The iter was then
evaluated as not equal to the End and the iter was getting dereferenced.
Since the iterator had m_table set to NULL, the dereferencing caused
crash.

The issue shows up as something like this:

Fatal error. Internal CLR error. (0x80131506)
at System.Reflection.LoaderAllocatorScout.<Destroy>g____PInvoke__|1_0(IntPtr)
at System.Reflection.LoaderAllocatorScout.Finalize()

The iteration that marks loader allocators in LoaderAllocator::Mark() was not being called under an appropriate lock, which lead to a rare and hard to reproduce race condition and a crash in the LoaderAllocator::Mark(). The issue happened when the m_LoaderAllocatorReferences.Begin() returned an iterator at the time the m_LoaderAllocatorReferences were empty and another thread has written something into those references before the m_LoaderAllocatorReferences.End() was called. The iter was then evaluated as not equal to the End and the iter was getting dereferenced. Since the iterator had m_table set to NULL, the dereferencing caused crash.

jkotas · 2022-04-21T16:55:22Z

 // Iterate through every loader allocator, marking as we go
 {
+ CrstHolder chLoaderAllocatorReferencesLock(pAppDomain->GetLoaderAllocatorReferencesLock());
 CrstHolder chAssemblyListLock(pAppDomain->GetAssemblyListLock());


The second iteration below is going to acquire same locks now. We can acquire the locks just once for the whole duration of both iterations.

Makes sense, I'll update the PR that way.

teo-tsirpanis · 2022-04-21T19:26:11Z

(setting the milestone to 7.0.0; the PR targets main, 6.0.x is for backports)

This change ports two unloadability fixes for issues found by a customer. * dotnet#68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * dotnet#68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction.

* [Release/6.0] Port unloadability fixes This change ports two unloadability fixes for issues found by a customer. * #68550 that adds reference between native `LoaderAllocator`s of two collectible `AssemblyLoadContexts` when one of them is used to resolve assembly using the other one. This reference ensures that the one that provides the resolved `Assembly` isn't collected before the one that uses it. * #68336 that adds a missing lock around `m_LoaderAllocatorReferences` iteration during assembly load context destruction. * Remove breaking change part The change in main has added an exception in case a collectible `Assembly` is resolved into a non-collectible `AssemblyLoadContext`. Although that is incorrect, there are cases when it would work. So the added exception is a breaking change that I think we likely don't want to get into 6.0

janvorli added the area-VM-coreclr label Apr 21, 2022

janvorli added this to the 6.0.x milestone Apr 21, 2022

janvorli requested review from davidwrighton and jkotas April 21, 2022 16:20

janvorli self-assigned this Apr 21, 2022

jkotas reviewed Apr 21, 2022
View reviewed changes

jkotas approved these changes Apr 21, 2022
View reviewed changes

Reflect PR feedback
73fc6ec

teo-tsirpanis modified the milestones: 6.0.x, 7.0.0 Apr 21, 2022

jkotas merged commit 233c40e into dotnet:mainApr 21, 2022

janvorli deleted the fix-loaderallocatorreferences-iteration-lock branch April 28, 2022 13:18

janvorli mentioned this pull request Apr 28, 2022
[release/6.0] Unloadability bugs fixes #68674
Merged

ghost locked as resolved and limited conversation to collaborators May 28, 2022

janvorli added the area-VM-coreclr label Apr 21, 2022

janvorli added this to the 6.0.x milestone Apr 21, 2022

janvorli requested review from davidwrighton and jkotas April 21, 2022 16:20

janvorli self-assigned this Apr 21, 2022

jkotas reviewed Apr 21, 2022
View reviewed changes

jkotas approved these changes Apr 21, 2022
View reviewed changes

Reflect PR feedback
73fc6ec

teo-tsirpanis modified the milestones: 6.0.x, 7.0.0 Apr 21, 2022

jkotas merged commit 233c40e into dotnet:mainApr 21, 2022

janvorli deleted the fix-loaderallocatorreferences-iteration-lock branch April 28, 2022 13:18

janvorli mentioned this pull request Apr 28, 2022
[release/6.0] Unloadability bugs fixes #68674
Merged

ghost locked as resolved and limited conversation to collaborators May 28, 2022

janvorli added the area-VM-coreclr label Apr 21, 2022

janvorli added this to the 6.0.x milestone Apr 21, 2022

janvorli requested review from davidwrighton and jkotas April 21, 2022 16:20

janvorli self-assigned this Apr 21, 2022

jkotas reviewed Apr 21, 2022
View reviewed changes

jkotas approved these changes Apr 21, 2022
View reviewed changes

Reflect PR feedback
73fc6ec

teo-tsirpanis modified the milestones: 6.0.x, 7.0.0 Apr 21, 2022

jkotas merged commit 233c40e into dotnet:mainApr 21, 2022

janvorli deleted the fix-loaderallocatorreferences-iteration-lock branch April 28, 2022 13:18

janvorli mentioned this pull request Apr 28, 2022
[release/6.0] Unloadability bugs fixes #68674
Merged

ghost locked as resolved and limited conversation to collaborators May 28, 2022

janvorli added the area-VM-coreclr label Apr 21, 2022

janvorli added this to the 6.0.x milestone Apr 21, 2022

janvorli requested review from davidwrighton and jkotas April 21, 2022 16:20

janvorli self-assigned this Apr 21, 2022

jkotas reviewed Apr 21, 2022
View reviewed changes

jkotas approved these changes Apr 21, 2022
View reviewed changes

Reflect PR feedback
73fc6ec

teo-tsirpanis modified the milestones: 6.0.x, 7.0.0 Apr 21, 2022

jkotas merged commit 233c40e into dotnet:mainApr 21, 2022

janvorli deleted the fix-loaderallocatorreferences-iteration-lock branch April 28, 2022 13:18

janvorli mentioned this pull request Apr 28, 2022
[release/6.0] Unloadability bugs fixes #68674
Merged

ghost locked as resolved and limited conversation to collaborators May 28, 2022

janvorli added the area-VM-coreclr label Apr 21, 2022

janvorli added this to the 6.0.x milestone Apr 21, 2022

janvorli requested review from davidwrighton and jkotas April 21, 2022 16:20

janvorli self-assigned this Apr 21, 2022

jkotas reviewed Apr 21, 2022
View reviewed changes

jkotas approved these changes Apr 21, 2022
View reviewed changes

Reflect PR feedback
73fc6ec

teo-tsirpanis modified the milestones: 6.0.x, 7.0.0 Apr 21, 2022

jkotas merged commit 233c40e into dotnet:mainApr 21, 2022

janvorli deleted the fix-loaderallocatorreferences-iteration-lock branch April 28, 2022 13:18

janvorli mentioned this pull request Apr 28, 2022
[release/6.0] Unloadability bugs fixes #68674
Merged

ghost locked as resolved and limited conversation to collaborators May 28, 2022

janvorli added the area-VM-coreclr label Apr 21, 2022

janvorli added this to the 6.0.x milestone Apr 21, 2022

janvorli requested review from davidwrighton and jkotas April 21, 2022 16:20

janvorli self-assigned this Apr 21, 2022

jkotas reviewed Apr 21, 2022
View reviewed changes

jkotas approved these changes Apr 21, 2022
View reviewed changes

Reflect PR feedback
73fc6ec

teo-tsirpanis modified the milestones: 6.0.x, 7.0.0 Apr 21, 2022

jkotas merged commit 233c40e into dotnet:mainApr 21, 2022

janvorli deleted the fix-loaderallocatorreferences-iteration-lock branch April 28, 2022 13:18

janvorli mentioned this pull request Apr 28, 2022
[release/6.0] Unloadability bugs fixes #68674
Merged

ghost locked as resolved and limited conversation to collaborators May 28, 2022

janvorli added the area-VM-coreclr label Apr 21, 2022

janvorli added this to the 6.0.x milestone Apr 21, 2022

janvorli requested review from davidwrighton and jkotas April 21, 2022 16:20

janvorli self-assigned this Apr 21, 2022

jkotas reviewed Apr 21, 2022
View reviewed changes

jkotas approved these changes Apr 21, 2022
View reviewed changes

Reflect PR feedback
73fc6ec

teo-tsirpanis modified the milestones: 6.0.x, 7.0.0 Apr 21, 2022

jkotas merged commit 233c40e into dotnet:mainApr 21, 2022

janvorli deleted the fix-loaderallocatorreferences-iteration-lock branch April 28, 2022 13:18

janvorli mentioned this pull request Apr 28, 2022
[release/6.0] Unloadability bugs fixes #68674
Merged

ghost locked as resolved and limited conversation to collaborators May 28, 2022

janvorli added the area-VM-coreclr label Apr 21, 2022

janvorli added this to the 6.0.x milestone Apr 21, 2022

janvorli requested review from davidwrighton and jkotas April 21, 2022 16:20

janvorli self-assigned this Apr 21, 2022

jkotas reviewed Apr 21, 2022
View reviewed changes

jkotas approved these changes Apr 21, 2022
View reviewed changes

Reflect PR feedback
73fc6ec

teo-tsirpanis modified the milestones: 6.0.x, 7.0.0 Apr 21, 2022

jkotas merged commit 233c40e into dotnet:mainApr 21, 2022

janvorli deleted the fix-loaderallocatorreferences-iteration-lock branch April 28, 2022 13:18

janvorli mentioned this pull request Apr 28, 2022
[release/6.0] Unloadability bugs fixes #68674
Merged

ghost locked as resolved and limited conversation to collaborators May 28, 2022

Uh oh!

Conversation

janvorli commented Apr 21, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

teo-tsirpanis commented Apr 21, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

janvorli commented Apr 21, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

teo-tsirpanis commented Apr 21, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

janvorli commented Apr 21, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

teo-tsirpanis commented Apr 21, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

janvorli commented Apr 21, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

teo-tsirpanis commented Apr 21, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

janvorli commented Apr 21, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

janvorli commented Apr 21, 2022•
edited
Loading

janvorli commented Apr 21, 2022•
edited
Loading

janvorli commented Apr 21, 2022•
edited
Loading

janvorli commented Apr 21, 2022•
edited
Loading

janvorli commented Apr 21, 2022•
edited
Loading

janvorli commented Apr 21, 2022•
edited
Loading