I noticed the bug fixed in r304440 when running
"truss -f make -C /usr/src/bin/cat". The fix exposed another bug: PT_TRACE_ME
shouldn't set P2_PTRACE_FSTP, since the first signal to stop a traced
process after an exec is SIGTRAP. This fix modifies proc_set_traced() to
allow the caller to indicate whether the process will be initially
stopped using SIGSTOP.
Details
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Shouldn't, instead of not setting the P2_PTRACE_FSTP flag, _ME code treat SIGTRAP same as SIGSTOP ? I.e. P2_PTRACE_FSTP causing issignal() to prefer SIGTRAP for the next selection ?
If yes, this can be done with either additional flag, or a new field in struct proc indicating which signal is FSTP.
(BTW, the inconsistency in SIGTRAP/SIGSTOP is definitely a confusing thing about ptrace()). I think it's probably safest to do this. I think a new field to indicate the expected signal number (can be passed as the second arg to proc_set_traced()) would work in terms of the API.
In this case the SIGTRAP is not intercepted from issignal(). Rather, syscallret() calls ptracestop(SIGTRAP) directly, and thus we're not really sending a signal to the traced process but rather just using ptracestop() to notify the tracing process about the exec of the tracee. So I don't think PT_TRACE_ME is susceptible to the same problem that r303423 attempted to fix. I'm not sure if this contradicts the intent behind your suggestion.