-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Crossgen outerloop regression: "Failed to convert invalid RVA to offset: <N>" #108255
Comments
The problem appears to be that the composite-r2r.dll generated on linux is corrupt or truncated; it's 4096 bytes while on Windows it's 144KB. The map files generated show that the Windows one is full of the things you'd expect, like 2183 symbols and 499 relocations, while the linux one has 56 symbols and 0 relocations. So I think R2RDump is correct here and the binary being dumped is just corrupt. |
My repro steps on linux (won't break on windows): ./build.sh Clr+Tools+Libs -c Release -rc Debug --os linux
./src/tests/build.sh debug -priority1 -crossgen2 -p:LibrariesConfiguration=Release -tree:JIT/Methodical/xxobj/sizeof/
PATH=/home/kate/Projects/dotnet-runtime-wasm/.dotnet/:$PATH RunCrossGen2=1 CompositeBuildMode=1 artifacts/tests/coreclr/linux.x64.Debug/JIT/Methodical/xxobj/sizeof/sizeof64_Target_64Bit_and_arm_r/sizeof64_Target_64Bit_and_arm_r.sh |
The truncation isn't caused by the not-on-windows section alignment logic. Comparison of the map files with it enabled/disabled: disabled
enabled
So disabling the section alignment doesn't fix the RVA being incorrect (it still points at the end of |
Anyone trying to bisect this in old previews (it appears to be broken as far back as net8.0 preview 2) will need to patch (EDITED) |
Passing
|
Most of these that were happening were due to a bug in tests.sh, but a few still remain. Examples:
|
On linux and osx hosts, crossgen r2rdump fails for a subset of tests right now fairly consistently, where the RVA of the auxiliary data points to the exact end of the .text section's virtual address space. There should be 4 bytes there, representing the length of the auxiliary data, or a NULL to indicate there is no auxiliary data. This does not appear to fail on windows, which seems to align with the comment in R2RPEBuilder.cs that suggests it doesn't patch any section headers on Windows:
Example with additional diagnostic data from PR #106099:
The artifacts for these failed runs don't appear to contain the actual binaries, which might be related to this:
The text was updated successfully, but these errors were encountered: