Page MenuHomeFreeBSD

Corestop.
Needs ReviewPublic

Authored by trasz on May 11 2020, 9:08 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 23 2023, 1:00 AM
Unknown Object (File)
Nov 28 2023, 8:32 PM
Unknown Object (File)
Nov 28 2023, 5:57 AM
Unknown Object (File)
Nov 23 2023, 4:27 AM
Unknown Object (File)
Nov 23 2023, 3:47 AM
Unknown Object (File)
Nov 23 2023, 3:37 AM
Unknown Object (File)
Nov 14 2023, 3:37 AM
Unknown Object (File)
Nov 14 2023, 3:09 AM

Details

Reviewers
kib
Group Reviewers
manpages
Summary

Add corestop - a mechanism to try to stop a process instead of dumping
core, and send out a devd(8) notification. This way devd can run a script
to gather various data related to the process, or trigger a snapshot of the
VM it's running in, so that the user can later restore the snapshot, log in,
and attach to the offending proccess with a debugger.

This is a kind of WIP - it works, but might not be the final shape;
comments are welcome.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 31235
Build 28884: arc lint + arc unit

Event Timeline

trasz requested review of this revision.May 11 2020, 9:08 PM

This only handles trapsignal(), so won't catch abort() from userland? (E.g. if a C++ exception isn't caught and unwinds to the bottom of the stack) Also, is the idea that then later do a SIGCONT to get a core dump by retrying the instruction (won't work for the abort() case)? Or to depend on the notification to send a SIGKILL?

For FreeBSD opting into this sort of thing might be something only certain processes want to do via a new procctl(2) flag or the like.

In D24813#546230, @jhb wrote:

This only handles trapsignal(), so won't catch abort() from userland? (E.g. if a C++ exception isn't caught and unwinds to the bottom of the stack) Also, is the idea that then later do a SIGCONT to get a core dump by retrying the instruction (won't work for the abort() case)? Or to depend on the notification to send a SIGKILL?

Sure it does not handle async signals.

For FreeBSD opting into this sort of thing might be something only certain processes want to do via a new procctl(2) flag or the like.

If process opts-in into this mode, it can instead fork/fork/exec gdb which attaches to the originator.

Overall this looks like mach debug servers (AFAIR) with very poor implementation. I am not sure that this can be useful except for small hacks.

sys/kern/kern_sig.c
2042

You never clear P2_CORESTOPPED.

Thanks for the review. I'm in the middle of rewriting the kernel part, so that instead of replacing the signal it handles things a bit lower down the stack; I'll try to avoid the problems you've pointed out.

Regarding the opt-in - I think that would make the mechanism somewhat harder to use; after all, the point of debugging is to force the process to cooperate in the first place.

For now, I'm updating the review to also include the userspace part.

Add the userspace part; kernel part will be updated in subsequent review.

Slightly less hacky, although still a bit buggy (SIGABRT doesn't
quite work) kernel part.

Am I going in the right direction?

sys/kern/kern_sig.c
3089

I think you should pass td as an argument.

3092

Why is this assert valid ?

Also, you should document, by asserts, all the locks that are assumed in this functions. The proc lock at least.

Which leads to the question, how wise is to log and send devctl notification under the process lock (and sigacts mutex as well).

3155

You basically loose the original signal there, I do not see how could the code work as intended, reliably.

trasz marked an inline comment as done.Jun 7 2020, 4:43 PM
trasz added inline comments.
sys/kern/kern_sig.c
3092

Is the assert ok now?

Regarding logs and devctl - I'm not sure. WITNESS doesn't yell about it, so I'm assuming it's ok? The sigacts mutex would be easy to get rid of; proc - not sure.

3155

I think I got it right this time. Or rather - as right as reasonably possible.

sys/kern/kern_sig.c
3001

If I would play with something like this, I would just changed this line to

if ((prop & SIGPROP_STOP) != 0 || (corestop && (prop & SIGPROP_CORE) != 0))

Then if SIGPROP_CORE is set, I would send notifications before stopping.

3853

You still never clear the flag.

3878

Again this erases any info about the signal.

3880

This is weird. More weird is that you stopping the process without notifying potential debugger.

3885

This block was copied/pasted. Can you refactor instead ?

3892

This is a recursion, perhaps infinite.

gbe added a subscriber: gbe.

OK from manpages.