Open Bug 1728963 Opened 3 years ago Updated 1 year ago

Extract memory information from the minidump whenever possible

Categories

(Toolkit :: Crash Reporting, enhancement)

enhancement

Tracking

()

People

(Reporter: gsvelto, Unassigned)

Details

Our crash-time memory measurements have two significant issues:

  • They've taken in the main process, so when a content process fails some per-process values might be wrong (virtual memory measurements on Windows for example)
  • Since the measurements are taken right after capturing a minidump the affected content process might be dying, or already dead, thus making the global measurements misleading

It would be best if we could extract as much memory information as possible from the minidump. On Windows the minidump already contains streams with memory information (the MINIDUMP_SYSTEM_MEMORY_STREAM for example). We should figure out if those contain the information we care about and compute the rest (for example by scanning the memory map). Additionally it would be good to add support for writing that information out in Linux and macOS too, instead of relying on the existing annotations.

There's a couple more things can be done here while processing a minidump, I'm adding them here so I don't forget:

  1. For 32-bit crashes we can compute the available address space at the time of crash directly by looking at the MemoryInfoList stream
  2. Similarly we can compute the largest available free block (this used to be the largest_free_vm_block field in the old stackwalker)
  3. On Windows, both on 32- and 64-bit crashes we can compute how much memory had been committed by the crashed process, this information could be extremely useful when dealing with OOMs
You need to log in before you can comment on or make changes to this bug.