readytorun\tests\mainv1.csproj TestLoadR2RImageFromByteArray test fails on MacOS and Linux

[davidwrighton]

Description

These failures appear to be different on MacOS vs Linux. The actual test is disabled by a comment in the src\tests\readytorun\tests\main.cs file.

Reproduction Steps

Re-enable src\tests\readytorun\tests\main.cs TestLoadR2RImageFromByteArray

Expected behavior

Test should pass

Actual behavior

On Linux, fails with an assert. On Linux, the process crashes.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

Test will not run correctly at all until #71357 is checked in.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[janvorli]

I've reproed this on macOS arm64. The problem is that we attempting to write a relocation to a memory region that was not mapped with MAP_JIT flag. So even though we call PAL_JitWriteProtect(true), it has no effect.
The image is loaded by AssemblyNative_LoadFromStream
The problem is that on macOS arm64, it is not possible execute stuff from memory that was not reserved as executable (mmap'ed with MAP_JIT flag), so we'll need to copy the PE data from the stream into a memory that was reserved with executability enabled.

I am going to debug it on Linux too to see what's wrong there.

[janvorli]

cc: @VSadov

[janvorli]

On Linux, we fail with this assert:

Assert failure(PID 18176 [0x00004700], Thread: 18176 [0x4700]): !pFlat->HasReadyToRunHeader()
    File: /home/janvorli/git/runtime/src/coreclr/vm/peimagelayout.cpp Line: 88
    Image: /home/janvorli/git/runtime/artifacts/tests/coreclr/Linux.x64.Debug/Tests/Core_Root/corerun

The comment before the assert says:

   85       // ConvertedImageLayout may be able to handle them, but the fact that we were unable to
   86       // load directly implies that MAPMapPEFile could not consume what crossgen produced.
   87       // that is suspicious, one or another might have a bug.
   88       _ASSERTE(!pFlat->HasReadyToRunHeader());

However, the MAPMapPEFile was never called in this case, as the data are coming from a buffer and not from a file.

[VSadov]

Looks like I assumed that every scenario where R2R is enabled goes through MAPMapPEFile.

I think we could make it work for byte arrays.
Another alternative is to just disable R2R in such case.

I wonder what happens on Windows?

[ivdiazsa]

Looks like I assumed that every scenario where R2R is enabled goes through MAPMapPEFile.

I think we could make it work for byte arrays. Another alternative is to just disable R2R in such case.

I wonder what happens on Windows?

Just did some experiments, and tried isolating the problematic test method, and it doesn't seem to reproduce on Windows. At least we're in the clear there.