runtime: Assert failure: `!pFlat->HasReadyToRunHeader()`

Seen in runtime-dev-innerloop:

1) https://dev.azure.com/dnceng/public/_build/results?buildId=1741950&view=logs&j=9db4066d-6bf0-549a-7716-e181239d2ea7&t=ee7de8a6-b1ed-5700-3f81-b0654bf893a4 2) https://dev.azure.com/dnceng/public/_build/results?buildId=1742050&view=logs&j=9db4066d-6bf0-549a-7716-e181239d2ea7&t=ee7de8a6-b1ed-5700-3f81-b0654bf893a4

  crossgen2 -> /Users/runner/work/1/s/artifacts/bin/coreclr/OSX.x64.Release/crossgen2/osx-x64/publish/
  
  Assert failure(PID 30724 [0x00007804], Thread: 157356 [0x266ac]): !pFlat->HasReadyToRunHeader()
      File: /Users/runner/work/1/s/src/coreclr/vm/peimagelayout.cpp Line: 87
      Image: /Users/runner/work/1/s/artifacts/bin/coreclr/OSX.x64.Release/crossgen2/osx-x64/publish/crossgen2
  
  /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmp837be50a24fb42d4918c050befffacf4.exec.cmd: line 2: 30724 Abort trap: 6           /Users/runner/work/1/s/artifacts/bin/coreclr/OSX.x64.Release/crossgen2/osx-x64/publish/crossgen2 /Users/runner/work/1/s/artifacts/bin/coreclr/OSX.x64.Debug/IL/System.Private.CoreLib.dll --out /Users/runner/work/1/s/artifacts/obj/Microsoft.NETCore.App.Crossgen2/Release/net7.0/osx-x64/S.P.C.tmp
/Users/runner/work/1/s/src/installer/pkg/sfx/Microsoft.NETCore.App/Microsoft.NETCore.App.Crossgen2.sfxproj(70,5): error MSB3073: The command "/Users/runner/work/1/s/artifacts/bin/coreclr/OSX.x64.Release/crossgen2/osx-x64/publish/crossgen2 /Users/runner/work/1/s/artifacts/bin/coreclr/OSX.x64.Debug/IL/System.Private.CoreLib.dll --out /Users/runner/work/1/s/artifacts/obj/Microsoft.NETCore.App.Crossgen2/Release/net7.0/osx-x64/S.P.C.tmp" exited with code 134.

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 23 (23 by maintainers)

Most upvoted comments

Ah, yes, if this is the test execution of crossgen2 after it has been published, that’s this logic:

  <Target Name="RunPublishedCrossgen" AfterTargets="PublishCrossgen"
          Condition="'$(TargetOS)' == '$(HostOS)' and '$(TargetArchitecture)' == '$(BuildArchitecture)'">
    <!-- Run the published crossgen if we're not cross-compiling -->
    <Exec Command="@(FilesToPackage) $(CoreCLRArtifactsPath)IL/System.Private.CoreLib.dll --out $(IntermediateOutputPath)S.P.C.tmp" Condition="'%(FileName)%(Extension)' == 'crossgen2$(ExeSuffix)'"
          ConsoleToMsBuild="true">
      <Output TaskParameter="ConsoleOutput" PropertyName="CrossgenOutput" />
      <Output TaskParameter="ExitCode" PropertyName="CrossgenExitCode" />
    </Exec>
    <Error Text="Crossgen failed with code $(CrossgenExitCode), output: $(CrossgenOutput)" Condition="$(CrossgenExitCode) != 0" />
  </Target>

Which notably runs against $(CoreCLRArtifactsPath)IL/System.Private.CoreLib.dll, which should not be R2Red.

agocke on May 2, 2022

The algorithms are the same for OSX and Unix in general, but we see these failures on OSX only. The main difference is that OSX has larger OS page and we align to that when we map.

I think we may not leave enough room between sections RVAs for potentially bigger alignment. That is my current theory.

VSadov on May 2, 2022

We need to set firm criteria but generally we’re labeling failures in PR validation/CI with blocking-clean-ci, if they have happened in the last 2 weeks or so and are not one off cases. Feel free to use this label.

danmoseley on Apr 28, 2022