Store unhandled exception info on stack in Native AOT

[agocke]

Allocates a span on the stack to hold the ToString of the exception, as well as a CrashRecord which contains a unique cookie that can be used to find the exception info.

Fixes #84636

[ghost]

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

Issue Details

---

null

Author:	agocke
Assignees:	agocke
Labels:	area-NativeAOT-coreclr
Milestone:	-

[MichalStrehovsky]

Would it make sense to also dump the ToString for the innermost InnerException? I'm just thinking how this would look like for various async goo and chances are the 1024 bytes are going to get eaten by uninteresting stuff.

Alternatively, would it make sense to call RhGetCurrentThreadStackBounds to see how much stack we have available and potentially allocate up to say, 50% of what's available? Not much is going to happen after this method so it feels it might be okay to get greedy?

[agocke]

@MichalStrehovsky What would you suggest for the inner exception info? Trying to concat both infos? Or just only store the inner exception if one exists?

[MichalStrehovsky]

@MichalStrehovsky What would you suggest for the inner exception info? Trying to concat both infos? Or just only store the inner exception if one exists?

Ideally @tommcdon or @mikem8361 could guide us to what is more important from diagnostics perspective. We could have just the inner, or we could add another pointer in CrashDumpRecord that points to it.

Right now, the Exception.ToString will have both stacks and both messages (unless someone overrode the ToString since we don't seal it) - it might get truncated, we don't know. It really depends on how structured the data should be. Whether a duplication would be okay. Whether we should only do it if there was truncation. Etc.

It's why I asked for a "spec" on how this should look like.

[jkotas]

more important from diagnostics perspective

It is hard to judge what's more important. I think the best we can do here is to try to format the complete message if there is enough space.

[tommcdon]

Ideally @tommcdon or @mikem8361 could guide us to what is more important from diagnostics perspective. We could have just the inner, or we could add another pointer in CrashDumpRecord that points to it.

We have an upcoming .NET 8 backlog item on the diagnostics team to investigate what is needed to include an a Native AOT dump so that it is actionable. So I think it is a bit too soon for the diagnostics team to have a strong opinion on specific design details. Feel free to move forward with the change as we can make changes to the algorithm as needed.

[agocke]

Anything else that I should do here? Or is this ready to go?

[jkotas]

Looks good to me (modulo a few cleanup nits). We can adjust the implementation as necessary in future.

[agocke]

Yup, I missed the remaining GetExceptionsForCurrentThread pieces. Should be gone now.

[agocke]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[agocke]

Test failures look unrelated.