When profiling an application that forks one or more new processes, operf will record samples for both the parent process and forked processes. This is also true even if the forked process performs an exec of some sort (e.g., execvp). If the process does not perform an exec, you will see that opreport will attribute samples for the forked process to the main application executable. On the other hand, if the forked process does perform an exec, then opreport will attribute samples to the executable being exec'ed.

To demonstrate this, consider the following examples. When using operf to profile a single application (either with the --pid option or command option), the normal opreport summary output (i.e., invoking opreport with no options) looks something like the following:

CPU_CLK_UNHALT...|
  samples|      %|
------------------
   112342 100.000 sprintft
	CPU_CLK_UNHALT...|
	  samples|      %|
	------------------
	   104209 92.7605 libc-2.12.so
	     7273  6.4740 sprintft
	      858  0.7637 no-vmlinux
	        2  0.0018 ld-2.12.so

But if you profile an application that does a fork/exec, the opreport summary output will show samples for both the main application you profiled, as well as the exec'ed program. An example is shown below where s-m-fork is the main application being profiled, which in turn forks a process that does an execvp of the memcpyt program.

CPU_CLK_UNHALT...|
  samples|      %|
------------------
   133382 70.5031 memcpyt
	CPU_CLK_UNHALT...|
	  samples|      %|
	------------------
	   123852 92.8551 libc-2.12.so
	     8522  6.3892 memcpyt
	     1007  0.7550 no-vmlinux
	        1 7.5e-04 ld-2.12.so
    55804 29.4969 s-m-fork
	CPU_CLK_UNHALT...|
	  samples|      %|
	------------------
	    51801 92.8267 libc-2.12.so
	     3589  6.4314 s-m-fork
	      414  0.7419 no-vmlinux