Update CoreClr to beta-25011-03 (master)#16064
Conversation
|
@gkhanna79, did something change very recently related to load contexts? This test is failing across most of the legs... looks like we're getting back a different type than the test expects: |
|
@stephentoub Can you please file an issue and disable the test? I will take a look. |
5302189 to
ca5865b
Compare
|
I have looked into this issue and understand what is happening. We did have a change to binder (dotnet/coreclr#9324) but that was unlikely to cause the problem. Summary is that this is a test issue. The test is expected to have the following call sequence (callstack grows from top to bottom): In the failing case, the JIT was inlining/optimizing out the method in the middle. As a result, when Assembly.Load would perform the stack walk to determine its caller, it would think Since After making the change to the test to ensure the dynamically emitted method will not be inlined, we get the expected callstack with the frame corresponding to the dynamically emitted assembly: At this point, Assembly.Load gets the correct caller, determines it is a dynamic assembly and gets it load context and proceeds to use that for binding the intended load, resulting in the expected behavior. I have pushed a PR for the test fix at #16069. CC @jkotas |
|
BTW, I did confirm that the test failure happens even without the change to the binder I referenced above and that the test fix works for both with and without the binder changes. |
|
Let's wait for CoreCLR build with the fix |
No description provided.