Unix crash reports not being submitted: `CaptureAllThreadContexts` hard-exits the process

Development Platform & Builds
, ,
1

Since jumping up from UE 5.6 to 5.8.2, we’ve noticed that the crash reporter seems to not always kick in after a crash. A cursory investigation seems to point to issues around FGenericPlatformMallocCrash::Free being a no-op for large pools, as well as the FString that is built over-allocates, and gets copied twice…

Our workaround is to disable the CaptureAllThreadStacksOnCrash, but it’s a bit of a bandaid. We’re on Kubuntu 22.04.

[Attachment Removed]

2

Steps to Reproduce
Any crash on Unix, with `unix.CaptureAllThreadStacksOnCrash` at its default of `true`. Even a simple launch -> `Debug Crash` console command fails to send anything. You should see these two lines immediately before the process disappears:

```

MallocCrash run out of memory allocating %u bytes, free %u bytes

Please increase LARGE_MEMORYPOOL_SIZE, exiting…

```

Setting `unix.CaptureAllThreadStacksOnCrash=false` restores reporting with no rebuild required, which is a workaround.

[Attachment Removed]

3

Hi Jackson,

Thank you for bringing this issue to our attention. Glad that you are able to work around the issue. This issue is actively being worked on by the development team. You can track progress for issue UE-397073 once it is mirrored on the Unreal Engine Public Issue Tracker if having full thread context is something you want in your crash reports in the future.

Best regards.

[Attachment Removed]

4

Upon Matthew Sorrels’ request, I was unable to repro it in a generic FirstPersonShooter template, BP or C++. I’ve attached the stderr & stdout, plus the log, from a launch of our project.

[Attachment Removed]

5

Thanks Jackson, I believe Matthew Sorrels was able to reproduce the issue under certaine plugin enable conditions which enlarge the temporary reporting buffer needs, causing a breach of the memory pool capacity.

Best regards.

[Attachment Removed]