Skip to content

Bug 1831094: Add a process reader and module reader for each platform#168

Open
afranchuk wants to merge 2 commits intorust-minidump:mainfrom
afranchuk:process-reader
Open

Bug 1831094: Add a process reader and module reader for each platform#168
afranchuk wants to merge 2 commits intorust-minidump:mainfrom
afranchuk:process-reader

Conversation

@afranchuk
Copy link
Copy Markdown
Contributor

This merges features from the firefox process_reader crate for bug 1831094, in a step toward using minidump-writer to read crash annotations on its own.

@afranchuk afranchuk force-pushed the process-reader branch 3 times, most recently from 32c1c29 to af7d19a Compare December 30, 2025 21:21
@Jake-Shadle Jake-Shadle removed their request for review January 9, 2026 08:51
@gabrielesvelto
Copy link
Copy Markdown
Contributor

Sorry I've been holding off reviewing this one but I was waiting for PR #167 first given the changes there are more urgent and both PRs end up touching the same functionality.

@afranchuk
Copy link
Copy Markdown
Contributor Author

Sounds good, I'll rebase once that is merged.

@marti4d
Copy link
Copy Markdown
Collaborator

marti4d commented Apr 1, 2026

@afranchuk I was talking to @gabrielesvelto yesterday. I don't want to hold up changes to minidump-writer any longer on my change. I keep thinking that I'm close to done only for there to be more undiscovered complexity. And I'm also going to be on PTO soon for a few weeks... I just don't think it makes sense for you to wait any longer.

Honestly -- If I have to redo the part where I go through the existing codebase and redirect all the I/O, that's not the major difficulty of the change anyway -- Everything else is 😆.

Copy link
Copy Markdown
Contributor

@gabrielesvelto gabrielesvelto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I just left a couple of questions

Comment thread src/module_reader.rs
}
}

#[inline]
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know these were in the original code but are the #[inline] directives really useful?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this method at least, perhaps not. Maybe it's to encourage the compiler to elide the enum variant checks to have less branching on that? I can see an argument for wanting reading bytes to be optimized. But then again, there's plenty of error-checking that needs to be done here anyway, so there's still overhead for every call.

Comment thread src/mac/module_reader.rs
Comment on lines +39 to +59
macro_rules! read_scroll {
( $T:ty , $mem:expr , $offset:expr , $ctx:expr ) => {{
let bytes = $mem.read($offset, <$T>::size_with(&$ctx) as u64)?;
let (value, _) = <$T>::try_from_ctx(bytes.as_ref(), $ctx)?;
value
}};
}

macro_rules! read_scroll_array {
( $T:ty , $mem:expr , $offset:expr , $count:expr , $ctx:expr ) => {{
let bytes = $mem.read($offset, (<$T>::size_with(&$ctx) * $count) as u64)?;
let mut vals = Vec::with_capacity($count);
let mut offset = 0;
for _ in 0..$count {
let (value, bytes_read) = <$T>::try_from_ctx(&bytes[offset..], $ctx)?;
offset += bytes_read;
vals.push(value);
}
vals
}};
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any particular reason why you used scroll specifically for the macOS module reader but not the other platforms?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It wasn't very intentional: we already had code for linux, so I didn't touch that much, and on windows the goblin interface provides some convenience methods to get what we need. The goblin macOS interface wasn't as convenient (it doesn't have a lazy interface), so I read it directly instead.

This better reflects what the type represents. This also absorbs the
`ProcessReader` type, which was poorly named as well, and adds a variant
which takes a MemReader by reference.
@afranchuk afranchuk force-pushed the process-reader branch 3 times, most recently from 3d33022 to 0812de8 Compare April 14, 2026 03:50
This renames the linux `MemReader` to be the `ProcessReader`, and adds
new implementations for mac and windows. The `ModuleReader`s have the
minimum features needed; they can be filled out more in the future.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants