Add env var to control createdump on MacOS

[mikem8361]

The COMPlus_DbgEnableElfDumpOnMacOS needs to be set to 1 along with all the other standard createdump env vars for dumps to be enabled on MacOS.

This is because ELF coredumps are generated on MacOS and we want customers to be very explicit and aware of what the are getting.

Change test harness to use the new env var

[ghost]

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

[mikem8361]

This “ELF coredumps on MacOS” feature is meant to be internal. I’m torn about adding how to enable it in the error message. Of course this is all open source so it not like we are hiding how to enable it.

[mikem8361]

Can someone approve of this PR? I think have addressed all the code review feedback.

[danmoseley]

Aside @mikem8361 -- couple questions (not blocking this PR of course)

In the vstest scenario, I assume vstest triggers dotnet dump collect? I'm a little unclear how that works given the process crashed - does it stay in a lingering state such that vstest can grab the dump?

Assuming so, how will native dump collection will work in test runs on macOS? You mentioned that this dump is only useful for analyzing managed failures using dotnet dump and SOS. Should dotnet dump trigger both kinds of dump - or will the OS collect a native dump?

cc @nohwnd

[mikem8361]

For crash/unhandled exception triggered dump generation, vstest just sets the configuration environment variables before running the test (including this new one for MacOS) and the runtime exec's createdump to generate the coredump. The runtime waits until createdump is finished and then terminates like it would if the env vars weren't set. For this scenario, dotnet-dump collect isn't involved or used.

For hang/timeout triggered dump generation, vstest is more explicit and uses the Microsoft.Diagnostics.NETCore.Client write dump API (the same one that dotnet-dump collect does) to tell (via the diagnostic server IPC channel) the runtime to trigger dump generation. This exec's createdump and waits until it finished but the runtime process continues running normally.

Yes, MacOS dumps generated by either of the above can only be analyzed by dotnet-dump analyze and only provided managed state with the SOS commands. For the native state, a MacOS system could be configured (with ulimit) for crash trigger and maybe a SIGABRT signal could be sent to trigger a hang/timeout dump but that terminates the process. @josalem has already ran into the native state limitations in the createdump generated ones and has some experience with our runtime test harness's hang/timeout dump generation with SIGABRT. I'm not sure vstest can or should configure/set up the system dumps.

[noahfalk]

LGTM

[danmoseley]

@mikem8361 thank you that is valuable clarification.

[danmoseley]

For hang/timeout triggered dump generation, vstest is more explicit and uses the Microsoft.Diagnostics.NETCore.Client write dump API >

Just checking my assumption -- with this PR also such dumps are now enabled for this mechanism as well (ie for hangs on macOS not just crashes)? It's just the triggering mechanism that's different, this scenario is now complete, is that right?

[mikem8361]

vstest will have to set this env var before launching any tests for createdump to work on MacOS regardless of how it is triggered.

FYI, @nohwnd

[danmoseley]

@nohwnd I guess you're unblocked to add the env var now? I saw microsoft/vstest#2495 but it doesn't set it there.

[nohwnd]

Missed these notifications, the env var is set correctly in vstest, and what Mike described above is how it is actually done.