[browser][CoreCLR][R2R] Filesystem timestamp tests load kernel32.dll through guarded IsInAppContainer

[lewing]

Description

Trimmed browser CoreCLR R2R library tests fail when filesystem timestamp tests initialize BaseGetSetTimes<T>. Its PlatformDetection.IsInAppContainer call throws DllNotFoundException for kernel32.dll, despite the helper having an early !IsWindows return before the Windows P/Invoke.

This is classified as R2R-only execution behavior rather than a missing trimming descriptor: a clean aggressively trimmed non-R2R run of an affected group passes. Eager P/Invoke fixup resolution is a possibility, but the precise cause has not been established.

Reproduction Steps

Build browser CoreCLR, libraries, host, packs, and host crossgen2. Reproduced on 798449390515fa02f4b20160bedc5e34f8fbdfb9 plus publishing prerequisite #133378 (245cb70d593f2c8f3a4e23bcc422e7da5926e15b), with the existing mobile filesystem and StreamConformance trimming descriptors also enabled for browser aggressive trimming.

XHARNESS_COMMAND=test-browser ./dotnet.sh build /t:Test \
  src/libraries/System.Runtime/tests/System.IO.FileSystem.Tests/System.IO.FileSystem.Tests.csproj \
  /p:TargetOS=browser /p:TargetArchitecture=wasm /p:RuntimeFlavor=CoreCLR /p:Configuration=Release \
  /p:PublishReadyToRun=true /p:EnableAggressiveTrimming=true \
  /p:Scenario=WasmTestOnChrome /p:InstallChromeForTests=true /p:XunitShowProgress=true

For the comparison, use clean project-specific browser-wasm obj/bin outputs, set PublishReadyToRun=false, retain EnableAggressiveTrimming=true, and add:

/p:WasmTestAppArgs="-class System.IO.Tests.File_GetSetTimes_SafeFileHandle"

Expected behavior

Browser execution should return false from PlatformDetection.IsInAppContainer without loading a Windows library, and the timestamp tests should run.

Actual behavior

The R2R suite completed with 6,454 total: 6,184 passed, 26 failed, 244 skipped. The failures share this type-initializer error:

System.TypeInitializationException: The type initializer for 'System.IO.Tests.BaseGetSetTimes`1' threw an exception.
---- System.DllNotFoundException: Unable to load shared library 'kernel32.dll' or one of its dependencies.
dynamic linking not enabled
   at System.PlatformDetection.get_IsInAppContainer()
   at System.IO.Tests.BaseGetSetTimes`1..cctor()

Affected methods are inherited timestamp cases such as SettingUpdatesProperties, SettingUpdatesPropertiesWhenReadOnly, SettingUpdatesPropertiesAfterAnother, TimesIncludeMillisecondPart, and TimesNotIncludeMillisecondPart, across File, FileInfo, Directory, and DirectoryInfo variants.

The clean trimmed non-R2R comparison group reports 14 total: 11 passed, 0 failed, 3 skipped.

Regression?

Unknown. Only R2R-on versus R2R-off was compared; both retain aggressive trimming.

Known Workarounds

Disable R2R. During library-test bring-up, quarantine the affected timestamp cases specifically for browser R2R while retaining interpreter coverage.

Configuration

Browser-wasm CoreCLR Release, macOS arm64 build host, Chromium 153.0.8010.0, SDK 11.0.100-rc.1.26420.103.

Other information

Found while standing up trimmed R2R library tests for #133193. #131874 describes different build-time P/Invoke/struct-mapping failures; this report concerns a runtime DLL load in a guarded platform-detection helper.

Note

This issue was generated by GitHub Copilot from local build and test results.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/crossgen-contrib
See info in area-owners.md if you want to be subscribed.

[lewing]

The same guarded-platform-probe failure affects networking: HTTP failed 577 cases through TestUtilities probes loading kernel32.dll or libSystem.Security.Cryptography.Native.Android, and WebSockets failed 117 cases through the Android ALPN probe.

A narrowly scoped workaround is to keep only TestUtilities.dll interpreted, using PublishReadyToRunExclude. With aggressive trimming unchanged:

• FileSystem: 6,210 passed, 244 skipped, zero failures, including all previously quarantined timestamp tests. Those timestamp quarantines have been removed.
• HTTP functional: 809 passed, 120 skipped, zero failures.
• WebSockets client: 315 passed, zero failures.

The served HTTP test assembly and System.Net.Http WASM files byte-match their compiler-generated R2R images; no TestUtilities native R2R image is emitted. This does not disable library R2R coverage. It isolates the failure to compiling the support assembly, rather than missing trimming descriptors. Eager resolution of platform-specific P/Invoke fixups remains a hypothesis, not a fully proven VM root cause.

Note

This update was generated by GitHub Copilot from local build and execution results.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[jkotas]

Duplicate of #133259

[lewing]

The failure still reproduces after #133773 with consistently rebuilt CI artifacts, so this is not SDK crossgen2 flow lag.

Structured inspection of build 1603680's LibraryTestsCoreCLR_R2R Build.binlog shows System.Runtime.Extensions.Tests used the in-build compiler:

Crossgen2InBuildDir = /__w/1/s/artifacts/bin/coreclr/browser.wasm.Release/x64/crossgen2/
Crossgen2Path = /__w/1/s/artifacts/bin/coreclr/browser.wasm.Release/x64/crossgen2/crossgen2
_CreateR2RImages > RunReadyToRunCompiler = .../crossgen2 --targetos:browser

The corresponding Helix job 99979e03-c8ff-4e09-bed4-556341a52a41 finished all 24 work items. Three batches failed only through TestUtilities.AdminHelpers.IsProcessElevated reaching SystemNative_GetEUid:

• System.Runtime.Extensions.Tests: 1 failure
• System.IO.MemoryMappedFiles.Tests: 2 failures
• System.IO.FileSystem.Tests: the read-only-file test family

All report DllNotFoundException: libSystem.Native / dynamic linking not enabled. This means #133773's module-level classification is still insufficient for a direct System.Native P/Invoke whose test-only entrypoint is absent from the prebuilt framework call-helper table. The original runtime browser guard is intentionally retained; the temporary bring-up workaround remains to keep only TestUtilities.dll interpreted while product and test assemblies stay R2R.

Note

This update was generated with GitHub Copilot from CI binlog and Helix evidence.

[jkotas]

TestUtilities.AdminHelpers.IsProcessElevated reaching SystemNative_GetEUid

Tests that P/Invoke directly into SystemNative_... shims do not represent supported user scenarios. These shims are internal implementation details of the core libraries and are not part of the supported surface. Code outside the core libraries should not P/Invoke them directly.

[jkotas]

Potential ways to fix this:

• Preferred: Update the test so that it does not call SystemNative_GetEUid directly. Some existing tests already avoid this by P/Invoking libc:

  runtime/src/libraries/System.IO.Pipes/tests/NamedPipeTests/NamedPipeTest.RunAsClient.Unix.cs

  Lines 19 to 20 in 229a331

  	[DllImport("libc", SetLastError = true)]
  	internal static extern unsafe uint geteuid();

• Alternatively, work around the issue in the tests somehow. Workarounds like that tend to be fragile.