Test that getppid() does not return an unrelated debugger.

[jhb]

Summary

Add a test to verify that a traced process sees its original parent via
getppid() after a debugger process that is not the parent has attached.

[kib]

I noted now that the test does not un-ignore and block SIGCHLD. Is it something guaranteed by the ATF execution environment ?

tests/sys/kern/ptrace_test.c

924 ↗

(On Diff #8627)

It is better to use _exit() in the forked child.

[jhb]

In D3615#74688, @kib wrote:

I noted now that the test does not un-ignore and block SIGCHLD. Is it something guaranteed by the ATF execution environment ?

Hmm, none of the tests do that. Isn't SIG_DFL sufficient for SIGCHLD however (discard signal, but still create zombies)? My guess is that ATF probably leaves SIGCHLD as the default action which should be SIG_DFL.

tests/sys/kern/ptrace_test.c

924 ↗

(On Diff #8627)

Hmm, I should probably do that in all of the various forked children in this set of tests. I can do that in a followup.

[jhb]

Use _exit() instead of exit() in child processes of new test.

[jhb]

tests/sys/kern/ptrace_test.c

924 ↗

(On Diff #8627)

I actually decided to fix this test before commit so I can more easily MFC the fix to the others. We haven't MFC'd this new behavior (getppid() not returning the tracer) probably to avoid what is effectively an ABI breakage of sorts in a stable branch, so this change may not get MFC'd unless the associated getppid() changes do.

[jhb]

Added ngie@. kib@ points out that these tests are assuming that ATF leaves SIGCHLD at its default disposition. Is that something that I should be able to safely assume or should I be explicitly setting SIGCHLD to SIG_DFL to be safe? (Related: would ATF consider it bad form to modify SIGCHLD's disposition?)

[ngie]

I think it leaves it in its "default disposition" based on a quick look around https://github.com/jmmv/kyua, but I'll add Julio just in case I'm missing something...