Disable runtime async feature on Apple mobile

[kotlarmilos]

Description

This PR disables runtime async feature on Apple mobile due to #124044.

[dotnet-policy-service]

Tagging subscribers to this area: @BrzVlad, @janvorli, @kg
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This pull request attempts to disable the runtime async feature in System.Diagnostics.StackTrace tests on Apple mobile platforms by conditionally setting EnablePreviewFeatures based on the TargetsAppleMobile property. The change is in response to test failures on Apple mobile with both CoreCLR and Mono runtimes.

Changes:

• Conditionally disable EnablePreviewFeatures on Apple mobile platforms in the test project file
• Remove the ActiveIssue attribute that was skipping the test on CoreCLR interpreter
• Add tracking issue reference for the problem

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/libraries/System.Diagnostics.StackTrace/tests/System.Diagnostics.StackTrace.Tests.csproj	Adds condition to only set EnablePreviewFeatures when not targeting Apple mobile, includes tracking issue comment
src/libraries/System.Diagnostics.StackTrace/tests/StackTraceTests.cs	Removes ActiveIssue attribute for CoreCLR interpreter on Apple mobile

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[jkotas]

This likely means that libraries tests with runtime async enabled are currently broken with interpreter (not just on AppleMobile platforms) and we will see it failing with other optional interpreter runs.

cc @agocke @janvorli

[janvorli]

This week I've started seeing some intermittent crashes on macOS arm64 in libraries tests that were not present approximately a week ago. It used to be stable before. So there is definitely some new issue.

[janvorli]

I am looking into it

[rcj1]

I have not examined the dump, but if this is limited to runtime-async runs as you say then this is what I expect based on my local testing. My changes expose an issue with the DiagnosticIP: #124044 (comment)

I can change the code to fail gracefully here and see if that resolves the issue - or at least allows for non-diagnostic related tests to run. #124089

[janvorli]

@rcj1 at least one of the failures I get consistently now is an incorrect object reference, I am not getting an assert on invalid codeinfo.

[rcj1]

@rcj1 at least one of the failures I get consistently now is an incorrect object reference, I am not getting an assert on invalid codeinfo.

Is the interpreter enabled here? Debug or release? Could you share the build where this is happening or a dump?

[rcj1]

Also relevant for MacOS arm64 is this issue, if you are seeing a crash on nativeAOT with runtime-async enabled - #124015

[janvorli]

Is the interpreter enabled here? Debug or release? Could you share the build where this is happening or a dump?

It is with interpreting everything (DOTNET_ReadyToRun=0 DOTNET_TieredCompilation=0 DOTNET_InterpMode=3), checked build of runtime, release build of libraries. The issue I've mentioned (Microsoft.Extensions.Http.Tests ) actually seems to go quite a long time back, I have likely missed it somehow. I wasn't able to find out yet when we started to hit it, I've tried to go about two weeks into the past and it still happened.

It always fails with this on top of the stack,

(lldb) clrstack
OS Thread Id: 0x56cc1ca (14)
        Child SP               IP Call Site
0000000170EC6330 0000000105B1FB30 System.Threading.Tasks.Task`1[[System.__Canon, System.Private.CoreLib]]..ctor(System.__Canon)
0000000170EC6360 0000000105B16E60 System.Threading.Tasks.Task.FromResult[[System.__Canon, System.Private.CoreLib]](System.__Canon)
0000000170EC6390 0000000105FADB4C Microsoft.Extensions.Http.Logging.HttpClientLoggerTest+TestRetryingHandler.SendAsyncCore(System.Net.Http.HttpRequestMessage, Boolean, System.Threading.CancellationToken)
0000000170EC63C0 0000000105FADA20 Microsoft.Extensions.Http.Logging.HttpClientLoggerTest+TestRetryingHandler.SendAsync(System.Net.Http.HttpRequestMessage, System.Threading.CancellationToken)
0000000170EC63F0 0000000105F3FC9C System.Net.Http.DelegatingHandler.SendAsync(System.Net.Http.HttpRequestMessage, System.Threading.CancellationToken)

it is executing this in the interpreter:

   2291                 case INTOP_STIND_O:
   2292                 {
   2293                     char *dst = LOCAL_VAR(ip[1], char*);
-> 2294                     OBJECTREF storeObj = LOCAL_VAR(ip[2], OBJECTREF);

And the failure is an access violation here:

* thread #14, name = '.NET TP Worker', stop reason = EXC_BAD_ACCESS (code=1, address=0x3001fec1000)
    frame #0: 0x0000000100f916bc libcoreclr.dylib`Object::ValidateInner(int, int, int) [inlined] Object::GetGCSafeMethodTable(this=0x000003001fec1000) const at object.h:366:59 [opt]
   363          // bit is reserved.  So if we want the actual MT pointer during a GC
   364          // we must zero out the lowest 2 bits on 32-bit and 3 bits on 64-bit.
   365  #ifdef TARGET_64BIT
-> 366          return dac_cast<PTR_MethodTable>((dac_cast<TADDR>(m_pMethTab)) & ~((UINT_PTR)7));
   367  #else
   368          return dac_cast<PTR_MethodTable>((dac_cast<TADDR>(m_pMethTab)) & ~((UINT_PTR)3));
   369  #endif //TARGET_64BIT

I'll check the other one failing I can see, that one fails intermittently.

[janvorli]

Ok, the other actually fails due to the codeinfo not being valid, it is the System.Text.Json.Tests

[janvorli]

@rcj1 I've just found that the other issue - the Microsoft.Extensions.Http.Tests one went away after a clean rebuild of the runtime.