Bug 134316

Summary: Callgrind does not distinguish between parent and child
Product: [Developer tools] valgrind Reporter: Christoph Bartoschek <bartoschek>
Component: callgrindAssignee: Josef Weidendorfer <josef.weidendorfer>
Status: ASSIGNED ---    
Severity: normal CC: njn
Priority: NOR    
Version: 3.2.1   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:

Description Christoph Bartoschek 2006-09-19 10:54:04 UTC
Callgrind reacts on requests to the parent in the child process. Requests done 
with callgrind_control are execued by the parent, the child or both.

Here is a testprogramm:

#include <cstdlib>
#include <cstdio>

extern "C" {
#include <unistd.h>
#include <sys/types.h>
}

int sum = 0;

int main() {

        if (fork() == -1) {
                perror("Could not create child");
                exit(-1);
        }
        while (true) {
                sleep(1);

                for (int i = 0; i < 100000000; ++i) sum += i;
        }
}


Compile it and run it with valgrind --tool=callgrind -v ./a.out

Then iterate

callgrind_control -i off <PID of parent>
callgrind_control -i on  <PID of parent>

and you might see something like that in the logfile:

--12409-- Command: instrumentation switched OFF
--12409-- Command: instrumentation switched ON
--12409-- Command: instrumentation switched OFF
--12409-- Command: instrumentation switched ON
--12409-- Command: instrumentation switched OFF
--12408-- Command: instrumentation switched OFF
--12409-- Command: instrumentation switched ON

Here 12408 is the pid of the parent and 12409 the pid of the child.
Comment 1 Christoph Bartoschek 2006-09-19 10:55:47 UTC
Ups. The bug is not a crash. In valgrind 3.2 this lead to a crash. But with valgrind 3.2.1 there is only the buggy behaviour.
Comment 2 Josef Weidendorfer 2006-09-19 12:05:59 UTC
I can confirm this.
It happens because some file names are prepared at startup which contain
the PID, and there is no hook in callgrind for fork.

As a patch probably will not be small and needs testing,
there was no need to hurry to put it into 3.2.1.
Comment 3 Nicholas Nethercote 2009-07-01 08:08:18 UTC
This is very similar to bug 162848.
Comment 4 Nicholas Nethercote 2009-07-01 09:31:18 UTC
This is very similar to bug 162848.