JIT/Methodical/tailcall_v4/hijacking/hijacking test hang

[jkotas]

Build Information

Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=1108433
Build error leg or test failing: JIT/Methodical/tailcall_v4/hijacking/hijacking.cmd
Pull request: #118160

Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": "tailcall_v4/hijacking/hijacking.cmd Timed Out",
  "ErrorPattern": "",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1108433
Error message validated: [tailcall_v4/hijacking/hijacking.cmd Timed Out]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 7/29/2025 2:26:35 PM UTC

Report

Build	Definition	Test	Pull Request
1113177	dotnet/runtime	JIT/Methodical/tailcall_v4/hijacking/hijacking.cmd	#118354
1108433	dotnet/runtime	JIT/Methodical/tailcall_v4/hijacking/hijacking.cmd	#118160

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
1	2	2

[jkotas]

The test times out while trying to suspend a thread that runs

Stacktrace of the thread that we failed to suspend:

coreclr!free_dbg_nolock+0xf1 [minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp @ 895] 
coreclr!_free_dbg+0x55 [minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp @ 1030] 
coreclr!operator delete+0x18 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\heap\delete_scalar.cpp @ 34] 
coreclr!operator delete[]+0x13 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\heap\delete_array.cpp @ 31] 
coreclr!TailCallTls::FreeArgBuffer+0x5 [D:\a\_work\1\s\src\coreclr\vm\threads.h @ 418] 
coreclr!TailCallTls::AllocArgBuffer+0xf0 [D:\a\_work\1\s\src\coreclr\vm\threads.cpp @ 97] 
coreclr!TailCallHelp::AllocTailCallArgBufferWorker+0xa2 [D:\a\_work\1\s\src\coreclr\vm\tailcallhelp.cpp @ 18] 
System_Private_CoreLib!System.Runtime.CompilerServices.RuntimeHelpers.AllocTailCallArgBuffer(Int32, IntPtr)+0xb [/_/src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/RuntimeHelpers.CoreCLR.cs @ 495] 
hijacking!ILStubClass.IL_STUB_StoreTailCallArgs(System.Object, Test_hijacking_il.ForceHelper, Test_hijacking_il.ForceHelper)+0x26
hijacking!Test_hijacking_il.Repro.TailHelper1(Test_hijacking_il.ForceHelper)+0x55
hijacking!ILStubClass.IL_STUB_CallTailCallTarget(IntPtr, Byte ByRef, IntPtr)+0x48
System_Private_CoreLib!System.Runtime.CompilerServices.RuntimeHelpers.DispatchTailCalls(IntPtr, Void (IntPtr, Byte ByRef, System.Runtime.CompilerServices.PortableTailCallFrame*), Byte ByRef)+0x5a [/_/src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/RuntimeHelpers.CoreCLR.cs @ 533] 
hijacking!Test_hijacking_il.Repro.TailCallThread()+0x37

Stacktrace of the thread that triggered GC:

coreclr!minipal_microdelay+0xd8 [D:\a\_work\1\s\src\native\minipal\time.c @ 173] 
coreclr!ThreadSuspend::SuspendAllThreads+0x279 [D:\a\_work\1\s\src\coreclr\vm\threadsuspend.cpp @ 3357] 
coreclr!ThreadSuspend::SuspendEE+0x488 [D:\a\_work\1\s\src\coreclr\vm\threadsuspend.cpp @ 5627] 
coreclr!GCToEEInterface::SuspendEE+0x48 [D:\a\_work\1\s\src\coreclr\vm\gcenv.ee.cpp @ 51] 
coreclr!WKS::GCHeap::GarbageCollectGeneration+0x2f6 [D:\a\_work\1\s\src\coreclr\gc\gc.cpp @ 51630] 
coreclr!WKS::GCHeap::GarbageCollectTry+0x63 [D:\a\_work\1\s\src\coreclr\gc\gc.cpp @ 50855] 
coreclr!WKS::GCHeap::GarbageCollect+0x246 [D:\a\_work\1\s\src\coreclr\gc\gc.cpp @ 50788] 
coreclr!GCInterface_Collect+0x18a [D:\a\_work\1\s\src\coreclr\vm\comutilnative.cpp @ 851] 
hijacking!Test_hijacking_il.Repro.Collector()+0x7a

[dotnet-policy-service]

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

[jkotas]

@jakobbotsch Do you happen to remember how the GC suspension is expected to work in this case? Are we missing an explicit GC poll somewhere along this path?

[jakobbotsch]

@jakobbotsch Do you happen to remember how the GC suspension is expected to work in this case? Are we missing an explicit GC poll somewhere along this path?

There shouldn't be anything special going on with helper-based tailcalls, so I would expect normal return address hijacking to be able to suspend the thread for these cases.

I looked at the dump. I see the same symptom as in #106134 (comment): TS_GCSuspendRedirected is set on the cooperative thread that we are trying to suspend, so all attempts to suspend it exit early without doing anything.