Comment 5 for bug 264711

Still something wrong with the tracing state machine.

From my previous log, it looks like things are coming out of order compared to how the state machine is expecting it. So here's my attempt of explaining the state machine...correct me if im wrong.

1) Upstart forks and sets up the trace on the new pid before exec'ing the new process. Set state to NEW.
2) Exec causes SIGTRAP, job_process_trace_new configures ptrace to look for fork's and exec's and continues the trace. Set state to NORMAL.
3) Process hits fork, upstart gets SIGTRAP with more information. job_process_trace_fork retrieves new pid info and saves it. Detaches from previous pid. Set state to NEW_CHILD.
4) The new child causes SIGSTOP. job_process_trace_new_child ultimately detaches from the new child. Set state to NONE.

What I'm seeing however, as seen in the previous log, is that the SIGSTOP and SIGTRAP at the point where the new fork happened is coming out of order. Basically, SIGSTOP is first (status 19) then SIGTRAP (status 261) second. Which then breaks the statemachine. The end result is that the final process is never allowed to continue is stays in the trace stopped state.

I think the state machine needs to be rewritten to assume those signals could happen in any order. The problem there is now you have to be careful of the variable trace_state, it needs to be protected.