Linux Crash Reporter can fail due to exceeding crash malloc space when generating the report

On Linux a crashing process can fail to produce a crash report at all. The crash folder is created and contains CrashContext.runtime-xml and Diagnostics.txt, but the copied log file is 0 bytes, CrashReportClient is never launched, and nothing is uploaded. The process exits with code 1.

Two lines are written to stderr when this happens:

MallocCrash run out of memory allocating 1048576 bytes, free 893392 bytes
Please increase LARGE_MEMORYPOOL_SIZE, exiting...

These go to stderr rather than the log, and the process ends in _exit(1), so buffered stdout is lost. Redirect stderr to a file to capture them.

Cause. Once a crash is being handled, GMalloc is replaced with FPlatformMallocCrash. Its large pool is 2MB and Free() is a no-op for that pool, so every allocation made while generating the report is permanent. Linux and Android are the only platforms that install this allocator. When the pool is exhausted the process calls RequestExit(true) and the report is lost.

Two allocations dominate the pool:

• Copying the engine log into the crash folder goes through IPlatformFile::CopyFile, which allocates a scratch buffer of min(1MB, log size). Any log larger than 1MB therefore takes half the pool in a single allocation.
• The all-thread callstack dump grows with thread count and is not bounded, and the accumulated thread XML is copied rather than moved when handed to the serializer.

The larger the crash context XML, the more likely this crash reporting failure becomes, so projects with many enabled plugins are affected first: the enabled plugin list is recorded in the crash context.

Workaround. Set unix.CaptureAllThreadStacksOnCrash=false. This restores crash reporting in most cases, at the cost of losing the per-thread callstacks.

Reproduced on 5.8 with a Linux editor build.

1. Use or create a project with a large number of enabled plugins. Around 400 enabled plugins reproduces reliably; the default editor plugin set plus most of the optional plugins is enough.
2. Launch the editor with verbose logging so the engine log grows past 1MB, capturing stderr:

   ./Engine/Binaries/Linux/UnrealEditor /path/to/Project.uproject \
       -ExecCmds="debug crash" -LogCmds="global Verbose" \
       -nosplash -unattended > /tmp/crash.out 2> /tmp/crash.err

3. Wait for the editor to finish loading and crash on the queued debug crash.

Result: no crash report is submitted. In Saved/Crashes/crashinfo-*/ the copied <Project>.log is 0 bytes and CrashReportClient.ini is absent, and /tmp/crash.err ends with the two MallocCrash lines shown in the description.

Expected: the crash report is written and submitted.

Notes on reproducing:

• FGenericPlatformMallocCrash prints "Malloc Size=<n> LargeMemoryPoolOffset=<n>" to stderr for every large-pool allocation, in every build configuration. The last offset before the failure is the high-water mark, which makes it directly measurable how close any given crash came to the limit.
• Both a large log and a large crash context are needed. A log under 1MB shrinks the CopyFile scratch buffer proportionally, and a small crash context leaves enough headroom to survive.
• If CrashContext.runtime-xml on your build records no enabled plugins, the crash context is much smaller and this is harder to hit.