2074790 - Detect corrupt annotations and report them

Status: NEW

(Toolkit :: Crash Reporting, enhancement)

Description

[Gabriele Svelto [:gsvelto]]

This is follow up work from bug 2074595 because the only information we got there was that an annotation that required copying a buffer (either a string or an actual byte buffer) was too large to contain proper data. I would rule out a corrupt C string because a null terminator would eventually pop up even in raw heap data, that leaves nsCStrings and byte buffers. So there's a few things we might want to do to figure out which annotation was corrupted and why:

• For nsCStrings we could fall back to scanning for a nul byte if the string appears to be longer than expected. We're already doing this but we're still loading the entire string in one go first.
• For byte buffers put a much shorter maximum, we only use it for small fixed-size buffers (I think that the largest would be sizeof(mozilla::phc::gAddrInfo)) so we can easily tell if something's wrong
• Finally for nul-terminated strings just use a maximum size and truncate so we get something
• Last but not least we should track which annotations we failed to read (or truncated) because these could point to an actual bug in the code which we cannot rule out. Ideally we'd put that in the minidump soft-error stream but we don't have access to that just yet. An alternative would be to add it to the DumperError annotation manually.

That being said finishing work around bug 1759682 would help there, as we'd be reading the annotations when the target process has been fully frozen by the minidump-writer and the soft error stream is available to record whatever we encounter.