You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The unloadability features in runtime don't track the lifetime of the shuffle thunks or the related delegate classes (looks like it happens only for delegates pointing to static methods) and when I have attempted to allocate them from the stub heap of the respective collectible loader allocator, they ended up being used after the loader allocator was destroyed and their underlying memory unmapped. That obviously resulted in crashes.
We should figure out how to track then in a way that would keep the loader allocator alive until all the shuffle thunks belonging to that allocator are destroyed.
The text was updated successfully, but these errors were encountered:
There was a problem with using heap from the related LoaderAllocator for
shuffle thunk cache heap. I have tested it again and it seems that the
issue is gone, most likely fixed by some recent fixes in the
unloadability area.
So I am removing the workaround, making the cache use LoaderAllocator
local heap.
I have also found a bug in decrementing stub refcount not using RW
mapping at one place while testing this change, so I have fixed it.
Closedotnet#55697
The unloadability features in runtime don't track the lifetime of the shuffle thunks or the related delegate classes (looks like it happens only for delegates pointing to static methods) and when I have attempted to allocate them from the stub heap of the respective collectible loader allocator, they ended up being used after the loader allocator was destroyed and their underlying memory unmapped. That obviously resulted in crashes.
We should figure out how to track then in a way that would keep the loader allocator alive until all the shuffle thunks belonging to that allocator are destroyed.
The text was updated successfully, but these errors were encountered: