Open
Bug 1728963
Opened 3 years ago
Updated 1 year ago
Extract memory information from the minidump whenever possible
Categories
(Toolkit :: Crash Reporting, enhancement)
Toolkit
Crash Reporting
Tracking
()
NEW
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.
Reporter | ||
Comment 1•3 years ago
|
||
There's a couple more things can be done here while processing a minidump, I'm adding them here so I don't forget:
- For 32-bit crashes we can compute the available address space at the time of crash directly by looking at the
MemoryInfoList
stream - Similarly we can compute the largest available free block (this used to be the
largest_free_vm_block
field in the old stackwalker) - 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.
Description
•