You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: