Page MenuHomeFreeBSD

Fix a regression in r303423.
ClosedPublic

Authored by markj on Aug 19 2016, 6:39 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Mar 21, 8:24 AM
Unknown Object (File)
Tue, Mar 19, 3:36 PM
Unknown Object (File)
Tue, Mar 19, 3:06 PM
Unknown Object (File)
Wed, Mar 6, 1:42 AM
Unknown Object (File)
Sun, Mar 3, 7:32 AM
Unknown Object (File)
Sun, Mar 3, 7:07 AM
Unknown Object (File)
Feb 12 2024, 3:06 AM
Unknown Object (File)
Jan 20 2024, 6:10 PM
Subscribers

Details

Summary

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.

Diff Detail

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

Event Timeline

markj retitled this revision from to Fix a regression in r303423..
markj edited the test plan for this revision. (Show Details)
markj updated this object.
markj added reviewers: kib, jhb.

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.

In D7576#157227, @kib wrote:

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 D7576#157227, @kib wrote:

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.

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.

kib edited edge metadata.

I see.

This revision is now accepted and ready to land.Aug 19 2016, 5:28 PM
This revision was automatically updated to reflect the committed changes.