This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: what does 'probe process(PID_OR_NAME).clone' mean?


David Smith <dsmith@redhat.com> writes:

> [...]
> It all boils down to what does "probe process(PID_OR_NAME).clone" mean?
> Or perhaps more precisely, when does "probe process(PID_OR_NAME).clone"
> get called?
> [...]
> (A) the pid 12345 .clone probe get called when pid 12345 calls fork()?
> (B) the pid 12345 .clone probe get called when a pid 12345 gets created?
> [...]

How about (C) neither: by conveniently defining the problem away.
Systemtap scripts don't really to know about clone events per se, but
rather when processes/threads come and go, and what syscalls they
perform.  The ".clone" event is currently implemented was sort of a
"this new thread/process was started due to a clone or fork", and not
the same thing as probing the parent's clone syscall.

So, to simplify the script level of the situation, here's the reduced
list of probe points dsmith and I tossed around yesterday:

process().begin, process().end
process().thread.begin, process().thread.end
process().syscall, process().syscall.return

The main delta from src/NEWS is the replacement of "exec" and "clone"
with "begin" and renaming "death" to "end", and the thread.begin/.end
probes.

So, for this scenario, here's the list of probes that could be hit:

    (login)
    bash%
    bash% ls
    foo bar
    bash% ^D

Here are the named-process probes:

process("bash").begin  # pid()=N
process("bash").begin  # forked process; ppid()=N; pid()=M
process("bash").end    # pid()=M  # NB: "bash"->"ls" process transition
process("ls").begin    # pid()=M
process("ls").end      # pid()=M
process("bash").end    # pid()=N

Here are the numbered-process probes:

process(N).begin  # pid()=N
process(M).begin  # forked process; ppid()=N; pid()=M
                  # N.B.: no .end/.begin for the "bash"->"ls" exec transition
                  # since process with pid=M is still just as alive
process(M).end    # pid()=M
process(N).end    # pid()=N

In there would of course be .syscall/.syscall.return probes.


For a multithreaded program doing some pthread_create() then an exec(),
which incidentally kills threads

process("parent").begin         # pid()=M
process("parent").thread.begin  # tid()=pid()=M
process("parent").thread.begin  # tid()=P,pid()=M
process("parent").thread.begin  # tid()=Q,pid()=M
                                # some thread starting a successful exec()
process("parent").thread.end    # tid()=pid()=M
process("parent").thread.end    # tid()=P
process("parent").thread.end    # tid()=Q
process("parent").end           # pid()=M; just ran the exec
process("child").begin          # pid()=M
process("child").thread.begin   # pid()=M
process("child").thread.end     # pid()=M
process("child").end            # pid()=M

For process-numbered probes, the same, except that the
thread.end/thread.begin pair around the exec() wouldn't show up
either, just like in the above case, since the original numbered
thread/process would survive the exec.


Does this make sense as the script-level view?


- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]