-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[EnC] FieldInfo.GetValue on a newly-added ValueType field crashes CoreCLR #76702
Comments
Tagging subscribers to this area: @dotnet/area-system-reflection Issue DetailsFound this while working on #76462, but it also reproduces with net7 (and probably net6.0 and older, see below) Repro:
// #define UPDATE
using System.Reflection;
public class Test {
public static void Main ()
{
bool stop = false;
Console.CancelKeyPress += new ((sender, ev) => {
ev.Cancel = true;
stop = true;
});
var c0 = new C();
int i = 0;
while (!stop) {
Body (ref i);
}
Console.WriteLine ("stopping");
GC.KeepAlive (c0);
}
static void Body (ref int i)
{
Console.WriteLine($"alive {i}");
i += 1;
Thread.Sleep (1000);
#if UPDATE
var c = new C();
var fi = c.GetType().GetField ("MyS");
var s = fi.GetValue (c); // bad!
Console.WriteLine ("still alive");
#endif
}
class C {
#if UPDATE
public S MyS;
#endif
public C() {
#if UPDATE
MyS = new S {
D = -1985.0,
O = new int[2] {15, 17},
};
#endif
}
#if UPDATE
public struct S {
public double D;
public object O;
};
#endif
}
}
Expected result: The hot reload change is applied and the application keeps running. Actual result:
That is, the child process - dotnet running the user code crashed with exit code 139. In #76462 we actually get a good combination of error messages from a CoreCLR builds on OSX and Windows, respectively: Mac:
Windows:
Which points to runtime/src/coreclr/vm/invokeutil.cpp Lines 1051 to 1061 in 8571fcb
This looks wrong - By the way, the same wrong logic is also in
|
Tagging subscribers to this area: @tommcdon Issue DetailsFound this while working on #76462, but it also reproduces with net7 (and probably net6.0 and older, see below) Repro:
// #define UPDATE
using System.Reflection;
public class Test {
public static void Main ()
{
bool stop = false;
Console.CancelKeyPress += new ((sender, ev) => {
ev.Cancel = true;
stop = true;
});
var c0 = new C();
int i = 0;
while (!stop) {
Body (ref i);
}
Console.WriteLine ("stopping");
GC.KeepAlive (c0);
}
static void Body (ref int i)
{
Console.WriteLine($"alive {i}");
i += 1;
Thread.Sleep (1000);
#if UPDATE
var c = new C();
var fi = c.GetType().GetField ("MyS");
var s = fi.GetValue (c); // bad!
Console.WriteLine ("still alive");
#endif
}
class C {
#if UPDATE
public S MyS;
#endif
public C() {
#if UPDATE
MyS = new S {
D = -1985.0,
O = new int[2] {15, 17},
};
#endif
}
#if UPDATE
public struct S {
public double D;
public object O;
};
#endif
}
}
Expected result: The hot reload change is applied and the application keeps running. Actual result:
That is, the child process - dotnet running the user code crashed with exit code 139. In #76462 we actually get a good combination of error messages from a CoreCLR builds on OSX and Windows, respectively: Mac:
Windows:
Which points to runtime/src/coreclr/vm/invokeutil.cpp Lines 1051 to 1061 in 8571fcb
This looks wrong - By the way, the same wrong logic is also in
|
@tommcdon @mikelle-rogers Here's a fun one |
|
Today I installed the latest nightly:
I used to get this error sometimes, then it went away. Now it is back. It could be because the most up to date nugets available are To reproduce, clone |
@tactical-drone This issue is about an Internal CoreCLR error in Edit and Continue and Hot Reload. It doesn't sound from your repro that you're using EnC. Would you mind opening a new issue? |
Found this while working on #76462, but it also reproduces with net7 (and probably net6.0 and older, see below)
Repro:
dotnet new console
dotnet watch
(but I believe this would also reproduce with EnC in Visual Studio)// #define UPDATE
to#define UPDATE
and save (or hit "Apply Changes" in VS)Expected result:
The hot reload change is applied and the application keeps running.
Actual result:
That is, the child process - dotnet running the user code crashed with exit code 139.
In #76462 we actually get a good combination of error messages from a CoreCLR builds on OSX and Windows, respectively:
Mac:
Windows:
Which points to
InvokeUtil::GetFieldValue
runtime/src/coreclr/vm/invokeutil.cpp
Lines 1051 to 1061 in 8571fcb
This looks wrong -
p = (*((BYTE**)target)) + pField->GetOffset() + sizeof(Object);
for fields added by EnC - they aren't at some offset, they're allocated entirely separately from the target object.By the way, the same wrong logic is also in
InvokeUtil::SetValidField
so probablyRtFieldInfo.SetField
/RuntimeFieldHandle.SetField
has issues too.The text was updated successfully, but these errors were encountered: