[Bug tapsets/9925] New: task_execname(task) incorrect in process.create

[Bug tapsets/9925] New: task_execname(task) incorrect in process.create

[cap at nsc dot liu dot se]

"task" in process.create is according to STAPPROBES.PROCESS(5):
 "a handle to the newly created process"

This seems to be true for some parts of "task" but not for all. The PID is
correct but execname is not (is actually the execname of the parent).

The following one-liner illustrates the issue:
 stap -e 'probe process.create { printf("currentpid: %d, newpid: %d,
newexecname: %s\n", pid(), task_pid(task), task_execname(task)) }'

With this running I started a few processes (/usr/bin/id, /bin/sleep) from my
bash resulting in:
 currentpid: 26872, newpid: 3156, newexecname: bash
 currentpid: 26872, newpid: 3157, newexecname: bash
 currentpid: 26872, newpid: 3158, newexecname: bash

In the data above currentpid (my bash) is correct, newpid (3156-3158) is also
correct. What's wrong is that newexecname should have been "id", "id", "sleep".

Tested on CentOS-5.3(QA) x86_64 (2.6.18-128.el5) with systemtap-0.7.2-2.el5 and
systemtap-20090228.

-- 
           Summary: task_execname(task) incorrect in process.create
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: cap at nsc dot liu dot se


http://sourceware.org/bugzilla/show_bug.cgi?id=9925

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/9925] task_execname(task) incorrect in process.create

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-03-05 17:00 -------
The output is "correct". The newexename is the same as the parent, since at
process.create time it has just forked itself , but hasn't execed a new process
yet, so the new process has the same name as the old process.

You probably want something like process.exec_complete:

$ stap -v -e 'probe process.exec_complete { printf("parentpid: %d, newpid: %d,
newexecname: %s\n", ppid(), pid(), execname()) }'

parentpid: 22997, newpid: 23674, newexecname: vim
parentpid: 22997, newpid: 23677, newexecname: ls


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9925

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/9925] task_execname(task) incorrect in process.create

[cap at nsc dot liu dot se]

------- Additional Comments From cap at nsc dot liu dot se  2009-03-05 17:01 -------
task_execname(task_current()) in process.start is wrong just like process.create

task_execname(task_current()) in process.begin works!
...but is not documented at all in STAPPROBES.PROCESS(5)


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9925

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/9925] task_execname(task) incorrect in process.create

[cap at nsc dot liu dot se]

------- Additional Comments From cap at nsc dot liu dot se  2009-03-05 17:05 -------
(In reply to comment #1)
> The output is "correct"

It may be expected (given what process.create really is) but it is not
"correct". That however can be fixed by updating the documentation...

The "task" in process.create is half the new process and half the old. I fear
this will confuse people even if the documentation/manpage is updated.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9925

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/9925] task_execname(task) incorrect in process.create

[dsmith at redhat dot com]

------- Additional Comments From dsmith at redhat dot com  2009-03-05 17:22 -------
(In reply to comment #3)
> (In reply to comment #1)
> > The output is "correct"
> 
> It may be expected (given what process.create really is) but it is not
> "correct". That however can be fixed by updating the documentation...

Which part of the documentation do you object to?

> The "task" in process.create is half the new process and half the old. I fear
> this will confuse people even if the documentation/manpage is updated.

I have to disagree with you - the "task" in process.create is fully the new
process.  Since the exec hasn't happened yet, execname is still that of the
parent, which is correct.  Remember that We have no guarantees that the new
process will do an exec at all - in the case of multi-threaded programs, this is
usually the case.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9925

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/9925] task_execname(task) incorrect in process.create

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-03-05 17:32 -------
(In reply to comment #3)
> It may be expected (given what process.create really is) but it is not
> "correct". That however can be fixed by updating the documentation...
> 
> The "task" in process.create is half the new process and half the old. I fear
> this will confuse people even if the documentation/manpage is updated.

It is as correct as we can be with the way Linux defines processes.

When a process calls fork(), a new process is created as an exact copy of the
old.  This is not half-anything -- it is a real bash process with a new PID. 
Then when the process calls exec(), that process starts running in a new
executable without changing PIDs.  From the kernel perspective, this is not a
new process at all.

From a user perspective, the completed combination of fork-exec represents a new
process, which is probably why you say it's half-done.  However, there's nothing
that says that fork and exec must happen back-to-back.  In general, fork and
exec can be called independently at any time.

For example, a daemon might be idle listening for incoming connections.  When a
connection comes in, it calls fork.  The new PID from the fork will handle the
request, while the old PID goes back to listening for other connections.  In
this case, you have a fork creating a new process, without ever having an exec.

You may also have execs without a fork.  Consider a command like "sudo ls".  The
process flow will look something like:

  pid-1 bash calls fork -> creates pid-2 bash
  pid-2 bash calls exec -> becomes pid-2 sudo
  (sudo changes the user id to root)
  pid-2 sudo calls exec -> becomes pid-2 ls

So many different combinations of fork/exec can occur...

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9925

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/9925] task_execname(task) incorrect in process.create

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-03-05 17:37 -------
(In reply to comment #4)
> Which part of the documentation do you object to?

I do think we need to separate up the multiple process tapsets (kprobes and
utrace).  It's not so good that we have things like process.create and
process.begin in the same namespace...

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9925

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/9925] task_execname(task) incorrect in process.create

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2009-03-06 01:27 -------
(In reply to comment #6)
> (In reply to comment #4)
> > Which part of the documentation do you object to?
> 
> I do think we need to separate up the multiple process tapsets (kprobes and
> utrace).  It's not so good that we have things like process.create and
> process.begin in the same namespace...
Agreed. The process test will be always failed in non-utrace kernel. It's noisy
result.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9925

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/9925] task_execname(task) incorrect in process.create

[cap at nsc dot liu dot se]

------- Additional Comments From cap at nsc dot liu dot se  2009-03-06 09:49 -------
Thanks for all the comments and explanations guys. You've convinced me that the
behaviour and documentation (for process.create) is ok.

Maybe the man page could be extended with a note regarding the state of "task"
at this probepoint for a typical fork+exec situation.

Also, unrelated, process.begin is missing from the man page.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9925

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/9925] task_execname(task) incorrect in process.create

[dsmith at redhat dot com]

------- Additional Comments From dsmith at redhat dot com  2009-03-06 14:18 -------
(In reply to comment #8)

> Also, unrelated, process.begin is missing from the man page.

Actually, process.begin probes are documented in the stapprobes man page.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9925

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/9925] task_execname(task) incorrect in process.create

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-03-14 01:13 -------
We've agreed that task_execname is behaving correctly, so I'm closing this. 
I've also filed bug9953 to suggest that the overlapping process.* tapsets need
to be resolved.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=9925

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.