Bugzilla

On Android, the crash helper sometimes aborts with `capacity overflow` right after writing a child process's minidump. Because the crash helper is not restarted on Android (bug 2039654), every later child crash in that session goes unreported. In geckoview-junit this shows up as `ContentCrashTest#crashContentJava` and the crash tests after it timing out, which is most of what gets classified under bug 1993445 on opt builds since July.

`finalize_breakpad_minidump` calls `mozannotation_server::retrieve_annotations`, which reads the child's annotation table out of its memory. An entry can be garbage when it is read (the child's other threads may still be updating the table), and `process_reader`'s `copy_array` sizes its allocation straight from the length in that entry with `Vec::with_capacity`, which panics once the length exceeds `isize::MAX`. Before bug 2050534 the same bad entries made `retrieve_annotations` segfault instead.

The attached patch makes `copy_array` check the size and reserve fallibly on all platforms, returning an error instead of panicking, and has `mozannotation_server` reject annotation lengths above 1 MiB and stop after `max_annotations` entries, so a bad entry is dropped and the minidump is still delivered. Why the entries are inconsistent in the first place (the table is read after the dump while the child may be running, without taking its mutex) is left for a follow-up.

On Android, the crash helper sometimes aborts with `capacity overflow` right after writing a child process's minidump. Because the crash helper is not restarted on Android (bug 2039654), every later child crash in that session goes unreported. In geckoview-junit this shows up as `ContentCrashTest#crashContentJava` and the crash tests after it timing out, which is most of what gets classified under bug 1993445 on opt builds since July.

https://treeherder.mozilla.org/logviewer?job_id=593278291&repo=autoland

`finalize_breakpad_minidump` calls `mozannotation_server::retrieve_annotations`, which reads the child's annotation table out of its memory. An entry can be garbage when it is read (the child's other threads may still be updating the table), and `process_reader`'s `copy_array` sizes its allocation straight from the length in that entry with `Vec::with_capacity`, which panics once the length exceeds `isize::MAX`. Before bug 2050534 the same bad entries made `retrieve_annotations` segfault instead.

The proposed patch makes `copy_array` check the size and reserve fallibly on all platforms, returning an error instead of panicking, and has `mozannotation_server` reject annotation lengths above 1 MiB and stop after `max_annotations` entries, so a bad entry is dropped and the minidump is still delivered. Why the entries are inconsistent in the first place (the table is read after the dump while the child may be running, without taking its mutex) is left for a follow-up.