Skip to content
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

Segfault handler should abort, or have the option to abort #80

Open
Matt-Esch opened this issue Jan 14, 2022 · 0 comments
Open

Segfault handler should abort, or have the option to abort #80

Matt-Esch opened this issue Jan 14, 2022 · 0 comments

Comments

@Matt-Esch
Copy link
Contributor

The segfault handler implementation on linux relies on the default handler to abort the process. It's doing this by setting the SA_RESETHAND flag, which reverts the handler to the default after the first execution. Incidentally this feature is a leftover artifact from a bug where the segfault handler used to get reset when it wasn't supposed to, and this flag restored the old buggy behaviour. So this implies that a segfault must occur twice for the process to exit. The first time the custom handler is called and the second time the default handler is called.

For example, this is obvious if you manually kill -SIGSEGV $pid - you have to send the signal twice, once to trap for the segfault handler and the second time is trapped by the default.

After the segfault has been trapped, the machine instruction is replayed. If replaying that instruction fails, the process will segfault again, and because the default handler has kicked in, the process will abort. There are however some situations where the replay will succeed. For example, if you're reading an area of memory that was not allocated when the fault was raised and the memory region is then allocated by another thread in the process.

Essentially the segfault handler should manually abort the process in the event of sigsegv rather than relying on the instruction to segfault twice, because this is unreliable.

I have worked around this by manually adding process.abort() to my custom handler, but this shouldn't be necessary.

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

No branches or pull requests

1 participant