Repository navigation
Evaluate writing out a MemoryInfoListStream #8
Description
To improve stack walking heuristics we'd like to validate ambiguous instruction pointers by checking if they fall within an executable reason. On Windows this is already possible because windbg.dll populates the MemoryInfoListStream with the whole state of the process' memory when it snapshots it. On Linux we currently have /proc/self/maps which contains the required information but we'd have to parse it in the stackwalker to yield the same information. Alternatively we might try and populate the MemoryInfoListStream on Linux too in order to be able to use the same code across different platforms.
Populating the stream should be relatively simple, info regarding the header and entries are readily available. The biggset issue is that the AllocationProtect, State, Protect and Type fields are supposed to contain Windows-specific constants. There's two ways to tackle this: either we use those fields to store Linux-specific constants - but that would defeat the purpose of having identical code for all platforms in the stack walker - or we map them to their closest Windows equivalents. Interestingly crashpad do
8000
es the latter for fuchsia but it does not populate the stream on Linux and macOS.
Activity
luser commentedon Mar 22, 2022
If someone writes a useful parser for
mapsyou could just reuse the same implementation in this crate + the stackwalker. :)afranchuk commentedon Jan 9, 2023
@luser Would
minidump-commonbe an okay common place for themapsparser? Or should it be a separate crate entirely?luser commentedon Jan 10, 2023
That doesn't quite feel like the right place for it, since currently
minidump-commonis mostly type definitions.n.b.: @Gankra implemented stackwalker parsing of this along with a unified interface atop that +
MemoryInfoListStreamin rust-minidump/rust-minidump#268 . See also rust-minidump/rust-minidump#256afranchuk commentedon Jan 10, 2023
I agree, I was asking on the off-chance that others didn't agree with my thought so it'd be simpler :)
Thanks for the info, I was aware of the existing impl. I was just going to move it somewhere common and maybe slightly clean up the interface so that it could be used in minidump-writer!
afranchuk commentedon Jan 10, 2023
Any suggestion on crate name/location? Alternatively, maybe we could contribute to the
procfscrate and expose itsprocess::MemoryMap::from_line()implementation?gabrielesvelto commentedon Jan 16, 2023
Contributing to an external crate sounds like a good idea if the crate is sufficiently widespread and useful. We parse
/procfiles in a lot of places within Firefox code and theprocfscrate sounds like something we'll end up using eventually.afranchuk commentedon Jan 16, 2023
Yeah, I figured with the other procfs needs we have, it'd be great to take advantage of
procfs. My only hesitation is thatprocfsdescribes itself as a crate for accessing the current system's procfs mount, so I'd like to confirm with the main developers as to whether they'd be okay with expanding the purpose of the crate (I don't expect anyone would have a problem with it, but it's best to confirm).afranchuk commentedon Jan 18, 2023
The
procfsteam seems open to contribution along these lines, so that is probably the path to follow.gabrielesvelto commentedon Jan 20, 2023
Excellent!
afranchuk commentedon Feb 8, 2023
I'm currently waiting (patiently, there's no rush) for
procfsto tag a new version. Then this can proceed.eminence commentedon Feb 9, 2023
procfsmaintainer here 👋 To set some rough expectations, I'm going to try to get a new release ofprocfsout within a week. Thanks to @afranchuk who did the implementation withinprocfsafranchuk commentedon Feb 9, 2023
@eminence thanks for chiming in with an update! I will set a reminder to check on things in a week.
Write a MemoryInfoListStream on linux.
Write a MemoryInfoListStream on linux.