1487197 - Linux minidump writer seems to do the wrong thing with short build IDs (< 20 bytes?)

Status: NEW

(Toolkit :: Crash Reporting, defect)

Description

[(not currently active) Ted Mielczarek]

bug 1485759 showed broken Android crash reports. In bug 1485759 comment 12 I determined that the build IDs from the libraries in question were shorter than usual (8 bytes vs. 20 bytes). glandium determined that lld defaults to `--build-id=fast`, which produces an md5 hash for the build id, vs bfd ld's default of sha1, which explains the difference. However, the real issue there was that while dump_syms was properly outputting the short build ID, the minidump writer was not. It seemed to be writing 20 bytes regardless. This is probably a bug in the code I wrote to handle build IDs in minidump writing originally.

From that bug:

For the crash in bug 1485759 comment 0, looking at the raw dump tab shows in the modules list:
 { "base_addr": "0xc7889000", "code_id": "62b09642416ac3f50100000090000000", "debug_file": "libxul.so", "debug_id": "4296B0626A41F5C301000000900000000", "end_addr": "0xcb2cf000", "filename": "libxul.so", "missing_symbols": true, "version": "" },

I downloaded the matching build:
https://queue.taskcluster.net/v1/task/ODjSM4BUSmOVwnkRxjSE2g/runs/0/artifacts/public/build/en-US/target.apk

And (after decompressing it with xz) the libxul.so in there shows a very short build id:

Displaying notes found at file offset 0x009100a0 with length 0x00000018:
  Owner                 Data size	Description
  GNU                  0x00000008	NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: 62b09642416ac3f5

dump_syms on that file produces:
$ dump_syms -i ./libxul.so 
MODULE Linux arm 4296B0626A41F5C300000000000000000 libxul.so
INFO CODE_ID 62B09642416AC3F5

Note that the code id in the dump_syms output matches the build id in the readelf output, and the debug id in the dump_syms output is just zero-padded to the length of a GUID, but the code_id and debug_id from the output of the stackwalker are both 20 bytes, and have some arbitrary trailing bytes there.

The bug is probably either in `MinidumpWriter::FillRawModule`:
https://dxr.mozilla.org/mozilla-central/rev/3205543f957cd2a6905486d73aa897535fdd9825/toolkit/crashreporter/breakpad-client/linux/minidump_writer/minidump_writer.cc#634

in `ElfClassBuildIDNoteIdentifier`:
https://dxr.mozilla.org/mozilla-central/rev/3205543f957cd2a6905486d73aa897535fdd9825/toolkit/crashreporter/google-breakpad/src/common/linux/file_id.cc#64

or in `auto_wasteful_vector` itself:
https://dxr.mozilla.org/mozilla-central/rev/3205543f957cd2a6905486d73aa897535fdd9825/toolkit/crashreporter/google-breakpad/src/common/memory_allocator.h#227

glandium disabled LTO for Android for now, and is explicitly passing `--build-id=sha1` to lld, so this probably won't be an issue for anything at the moment, but it'd still be good to fix.