-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Test failure JIT\\Regression\\VS-ia64-JIT\\V2.0-Beta2\\b311420\\b311420\\b311420.cmd #66969
Comments
There also seems to be some weird Windows loader effect going on. I have noticed that if I build the bad commit, then run |
We have been hitting bad exe format error in the CI for quite some time on various windows targets, @trylek was investigating it, but was never able to repro it locally. The current theory was that it is something in the CI causing problems with access to the file being loaded, like an antivirus or something like that. |
Are you sure it is the same issue? The above is reproducing reliably for me after eb8460f. Whenever I run |
I think these are two separate issues. The bug I'm still investigating mostly manifests when loading managed components of Crossgen2 and is rather sporadic whereas this bug is related to the load of native coreclr.dll and seems quite prevalent. In fact I have just nailed down the cause of #66954 and it might explain the managed component load issue as the problem is a race condition around assembly / native image loading that can make the runtime start using an assembly before it is sufficiently loaded. |
It seems there is a linker bug related to control-flow guard that is causing dotnet#66969. In eb8460f a thunktemplates.asm file was added that has a LEAF_END_MARKED at the end of the file. This creates two symbols for the same upcoming address. Normally that should be fine, but in this case it causes the linker to place the same address twice in a CFG table in the PE file. This causes the kernel to fail while loading the image. A simple workaround would be to add a nop at the end of thunktemplates.asm, but @janvorli suggested giving these symbols their own address in all cases for goodness when debugging. We already do so for Windows x64 it looks like. Fix dotnet#66969
Right, I have misread the coreclr.dll in the comment as System.Private.CoreLib.dll first. |
…ug (#66999) It seems there is a linker bug related to control-flow guard that is causing #66969. In eb8460f a thunktemplates.asm file was added that has a LEAF_END_MARKED at the end of the file. This creates two symbols for the same upcoming address. Normally that should be fine, but in this case it causes the linker to place the same address twice in a CFG table in the PE file. This causes the kernel to fail while loading the image. A simple workaround would be to add a nop at the end of thunktemplates.asm, but @janvorli suggested giving these symbols their own address in all cases for goodness when debugging. We already do so for Windows x64 it looks like. Fix #66969
…ug (dotnet#66999) It seems there is a linker bug related to control-flow guard that is causing dotnet#66969. In eb8460f a thunktemplates.asm file was added that has a LEAF_END_MARKED at the end of the file. This creates two symbols for the same upcoming address. Normally that should be fine, but in this case it causes the linker to place the same address twice in a CFG table in the PE file. This causes the kernel to fail while loading the image. A simple workaround would be to add a nop at the end of thunktemplates.asm, but @janvorli suggested giving these symbols their own address in all cases for goodness when debugging. We already do so for Windows x64 it looks like. Fix dotnet#66969
Run: runtime-coreclr r2r 20220320.1
Failed test:
Error message:
The text was updated successfully, but these errors were encountered: