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
If I run the test using set RunCrossGen2=1 but without crossgen-ing the framework, I get:
BEGIN EXECUTION
"C:\gh\runtime3\artifacts\tests\coreclr\windows.x86.Checked\Tests\Core_Root\corerun.exe" -p "System.Reflection.Metadata.MetadataUpdater.IsSupported=false" Runtime_31615.dll
Check at line 235 failed; have (1.0842106E-19,-1.0842106E-19,-1.5845755E+29,1.0842106E-19); expected (10,20,30,40)
Check at line 246 failed; have (-1.0842106E-19,1.0842106E-19,1.0842106E-19,-1.5845755E+29); expected (20,10,40,30)
Check at line 313 failed; have (1.0842106E-19,-1.0842106E-19,-1.5845755E+29,1.0842106E-19); expected (10,20,30,40)
Failed; 3 errors in 20 tests
Expected: 100
Actual: -1
END EXECUTION - FAILED
FAILED
(this is the actual failure, not the "Actual: False")
#76491 (I assume) exposed a bug that manifests as us getting the address for insertps data wrong, they are one byte before (or 15 bytes after?) from where they should be:
Activity
BruceForstall commentedon Dec 5, 2022
Looks like failures are all Windows x86 R2R
BruceForstall commentedon Dec 5, 2022
First failure was https://dev.azure.com/dnceng-public/public/_build/results?buildId=93803&view=results (runtime-coreclr outerloop build 20221125.2)
BruceForstall commentedon Dec 5, 2022
Maybe due to #76491?
cc @SingleAccretion @dotnet/jit-contrib
SingleAccretion commentedon Dec 5, 2022
I will take a look tomorrow.
BruceForstall commentedon Dec 5, 2022
If I run the test using
set RunCrossGen2=1but without crossgen-ing the framework, I get:(this is the actual failure, not the "Actual: False")
Disable Runtime_31615
Disable Runtime_31615 (#79252)
BruceForstall commentedon Dec 6, 2022
Note: test has been disabled and must be re-enabled when this is fixed.
SingleAccretion commentedon Dec 7, 2022
I investigated this a bit.
#76491 (I assume) exposed a bug that manifests as us getting the address for
insertpsdata wrong, they are one byte before (or 15 bytes after?) from where they should be:Notable: only reproduces without VEX encoding on x86 (hence the particular nature of failures).
Not yet clear where the actual bug is or how the fix looks like.
Only apply addlDelta for IMAGE_REL_BASED_REL32 relocs