Parallel Powershell sessions lead to corruption of the StartUpProfileData cache created by `ProfileOptimization.StartProfile`

[daxian-dbw]

Description

We PowerShell team got a new report about the profile data created by ProfileOptimization.StartProfile got corrupted by parallel PowerShell session started by pwsh -command. This happened on macOS and GitLab runners with PowerShell v7.5.4, which runs on top of .NET 9.0.

• Parallel Powershell Sessions Lead to Corruption of the StartUpProfileData Cache PowerShell/PowerShell#26528

Please see the detailed bug report in the PowerShell issue, including a .ips crash report collected on macOS.

I reported a similar issue #81799 a couple years back, and that was fixed in .NET 9.0. However, this still happens on .NET 9, indicating that the root cause may be different. /cc @mangod9 and @kouvel from #81799.

Reproduction Steps

The PowerShell issue PowerShell/PowerShell#26528 has the repro script.

Expected behavior

The profile file created by parallel PowerShell doesn't get corrupted.

Actual behavior

The profile seems corrupted by parallel PowerShell session.

Regression?

It could be a regression. We didn't hear the same issue before.

Known Workarounds

There is no workaround. Deleting the profile can temporarily fix the issue, but the next parallel run of PowerShell may run into the same issue.

Configuration

Which version of .NET is the code running on?
.NET 9

What OS and version, and what distro if applicable?
GitLab runners on macOS that don't use any sort of virtualization

Other information

No response

[dotnet-policy-service]

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

[agocke]

@kg Could you take a quick look and see if it's the same or similar to the issue you fixed for 9?

[kg]

This looks like a different bug. It is most likely a race condition between processes all sharing the same profile data file. Off-hand I don't know what the best fix would be other than trying to protect against the race with some sort of system wide mutex and silently skipping MCJ if the mutex can't be acquired.

[agocke]

@AndyAyersMS @davidwrighton I can't tell, is this intended use of this API? Is it supposed to be concurrency-safe?