-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Write stacks correctly during stack overflows #78
Conversation
This is a WIP, I need to test it in real world scenarios and add tests too. |
a604403
to
d8179ce
Compare
This is better, it works in Firefox so I will be able to add tests soon. There's still a couple of things that need to be hashed out:
|
f92b998
to
cc90c1e
Compare
a2c68a5
to
d1c35f4
Compare
When encountering a stack overflow we often crash accessing the guard page. The logic assumed that wherever the stack pointer was so was the stack, but this lead the writer to dump the guard page in these cases. This patch changes the logic to inspect the properties of the mapping that appears to correspond to the stack and - if it looks like a guard page - look for the actual stack instead. This change also removes the double limitation we had when retrieving stacks on Linux: previously the logic would only grab the first 32 KiB of each stack before checking for user-specified limits. Now only the user-specified limits are enforced and - if not present - the full stack is stored in the minidump. This brings the behavior in line with minidumps generated on Windows by windbg.dll. This fixes rust-minidump#24
d14dfe9
to
04bfdb7
Compare
This is as good as it gets, I tried to match the original intent, removing the redundant limit on the amount of stack we captured while ensuring we always grab a stack, provided the overflow is within 1MiB of where it should be as that's the size of guard pages in Linux ATM. |
@Jake-Shadle would you have time to take a look? |
Oh sorry, this completely fell off my radar, will review tomorrow! |
Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, can cut a release on Monday unless there is a rush.
|
||
pub fn is_executable(&self) -> bool { | ||
self.permissions.contains(MMPermissions::EXECUTE) | ||
} | ||
|
||
pub fn is_readable(&self) -> bool { | ||
self.permissions.contains(MMPermissions::READ) | ||
} | ||
|
||
pub fn is_writable(&self) -> bool { | ||
self.permissions.contains(MMPermissions::WRITE) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These could be inline, but that's just a nit.
No rush at all. |
When encountering a stack overflow we often crash accessing the guard page. The logic assumed that wherever the stack pointer was so was the stack, but this lead the writer to dump the guard page in these cases. This patch changes the logic to inspect the properties of the mapping that appears to correspond to the stack and - if it looks like a guard page - look for the actual stack instead.
This fixes #24