[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? |
mikelle-rogers
added
the
enhancement
tommcdon
removed
the
enhancement
ghost
added
the
in-pr
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
Found this while working on #76462, but it also reproduces with net7 (and probably net6.0 and older, see below)
Repro:
dotnet new consoledotnet watch(but I believe this would also reproduce with EnC in Visual Studio)// #define UPDATEto#define UPDATEand 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::GetFieldValueruntime/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::SetValidFieldso probablyRtFieldInfo.SetField/RuntimeFieldHandle.SetFieldhas issues too.The text was updated successfully, but these errors were encountered: