[hot_reload] Calling a method for the first time after an update crashes the app #57643
Comments
|
Tagging subscribers to 'arch-wasm': @lewing Issue Detailswith dotnet.6.0.0-rc.1.21411.2.js
|
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
dotnet-issue-labeler
bot
added
the
untriaged
jeffschwMSFT
removed
the
untriaged
|
The interesting thing about "ctrl-R" is that it is like we're in a cold-start situation. We start the runtime. Immediately apply an update to a method we never called before. We indirectly try to call it. So we're on some "let's interpret this method for the first time" path. |
lambdageek
changed the title
|
Some assertions that may be hit:
Can happen in the "src/mono/samples/mbr/console" sample, too - just change the main Program.cs code to apply the update before calling the test method. |
|
FYI @danroth27 |
|
When you are talking about applying deltas, It seems to me that we expect that the state of the browser is in sync with state of the server ? I guess I could have many browser tabs of different age-of-last-reload. |
I believe |
The issue is that the ParamList column in EnC deltas is a "suppressed column" that has the value 0. So when a method is updated if we use the value directly, we will break, for example - `mono_metadata_get_param_attrs` which expects a non-zero index in that column. CoreCLR solves this by having a set of suppressed columns that are never updated by deltas. (CoreCLR's model is to directly mutate the tables of the baseline image). In Mono we can eventually do the same thing by writing the value from the previous generation into the current delta's row. But right now since we don't allow parameter modifications, and the only column on a Method table that we allow to be modified is the RVA - which we look up specially - we can just always return the baseline image row for the method table. Fixes dotnet#57643
ghost
added
the
in-pr
The issue is that the ParamList column in EnC deltas is a "suppressed column" that has the value 0. So when a method is updated if we use the value directly, we will break, for example - `mono_metadata_get_param_attrs` which expects a non-zero index in that column. CoreCLR solves this by having a set of suppressed columns that are never updated by deltas. (CoreCLR's model is to directly mutate the tables of the baseline image). In Mono we can eventually do the same thing by writing the value from the previous generation into the current delta's row. But right now since we don't allow parameter modifications, and the only column on a Method table that we allow to be modified is the RVA - which we look up specially - we can just always return the baseline image row for the method table. Fixes #57643
ghost
removed
the
in-pr
|
Keeping open until the .NET 6 RC1 backport goes in |
ghost
added
the
in-pr
…57799) * Add test case Call a method for the first time after an update has been applied to it. This will check that the interpreter or JIT does not have to rely on cached information from the baseline (about the method signature, for example) and that it can compute it from the delta. * [hot_reload] Don't look at delta method table rows The issue is that the ParamList column in EnC deltas is a "suppressed column" that has the value 0. So when a method is updated if we use the value directly, we will break, for example - `mono_metadata_get_param_attrs` which expects a non-zero index in that column. CoreCLR solves this by having a set of suppressed columns that are never updated by deltas. (CoreCLR's model is to directly mutate the tables of the baseline image). In Mono we can eventually do the same thing by writing the value from the previous generation into the current delta's row. But right now since we don't allow parameter modifications, and the only column on a Method table that we allow to be modified is the RVA - which we look up specially - we can just always return the baseline image row for the method table. Fixes #57643 Co-authored-by: Aleksey Kliger <alklig@microsoft.com>
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
If a hot reload delta is applied to a method
Mthat has never been called before, and then that method is called for the first time after the update, the runtime will assert.A common variant of this is doing a browser refresh of a Blazor WebAssembly app that had some changes applied. When the runtime restarts,
dotnet watchreplays the deltas on a fresh runtime, and after that calling any of the updated methods will cause a crash.Original report:
with dotnet.6.0.0-rc.1.21411.2.js
dotnet new blazorwasmPages\Index.razorwith https://gist.github.com/pavelsavara/52bf2a7e3625bdbb747473fb6b2ba432dotnet new watchPages\Index.razorto https://gist.github.com/pavelsavara/06ca4d3d420ff72ec526bd59721c7210 & saveThe text was updated successfully, but these errors were encountered: