|
From: Christoph B. <bar...@or...> - 2006-09-13 08:36:24
|
Hi, I start our program with the option --trace-children=no but callgrind still seems to profile the child our program starts. In the directory I see one logfile for the main programm vg.19970 and two callgrind logfiles (callgrind.out.19970 and callgrind.out.19972). How to prevent the behaviour? Christoph |
|
From: Tom H. <to...@co...> - 2006-09-13 08:40:14
|
In message <200...@or...>
Christoph Bartoschek <bar...@or...> wrote:
> I start our program with the option --trace-children=no but callgrind still
> seems to profile the child our program starts.
Are you actually doing an exec(), or just a fork()?
You see trace-children is a bit badly named as it doesn't control
tracing over fork but tracing over exec, so if you fork but don't
actually exec a new program it will still be traced.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Christoph B. <bar...@or...> - 2006-09-13 09:01:32
|
Am Mittwoch, 13. September 2006 10:40 schrieb Tom Hughes: > In message <200...@or...> > > Christoph Bartoschek <bar...@or...> wrote: > > I start our program with the option --trace-children=no but callgrind > > still seems to profile the child our program starts. > > Are you actually doing an exec(), or just a fork()? > > You see trace-children is a bit badly named as it doesn't control > tracing over fork but tracing over exec, so if you fork but don't > actually exec a new program it will still be traced. > > Tom I do not have the source of the program, but with strace I see that the new child is created with clone: clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2aaaaada62d0) = 20888 And then no execve is performed because the functionality of the child is in the same programimage. Christoph |
|
From: Tom H. <to...@co...> - 2006-09-13 09:13:50
|
In message <200...@or...>
Christoph Bartoschek <bar...@or...> wrote:
> I do not have the source of the program, but with strace I see that the new
> child is created with clone:
>
> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> child_tidptr=0x2aaaaada62d0) = 20888
>
> And then no execve is performed because the functionality of the child is in
> the same programimage.
On recent linux systems fork is actually done with clone so you do
have the situation I described.
Unfortunately --trace-children is not going to help you.
The problem is that valgrind can't really untangle itself from an
existing process, so it is only on an exec (when the process image
in memory is completely replace) that we can remove ourselves.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dennis L. <pla...@pr...> - 2006-09-13 12:17:25
|
Am Mittwoch, den 13.09.2006, 10:13 +0100 schrieb Tom Hughes: > > On recent linux systems fork is actually done with clone so you do > have the situation I described. > > Unfortunately --trace-children is not going to help you. > > The problem is that valgrind can't really untangle itself from an > existing process, so it is only on an exec (when the process image > in memory is completely replace) that we can remove ourselves. Can't V fork() itself and then exec the program that its running? Or something like that? greets Dennis |
|
From: Tom H. <to...@co...> - 2006-09-13 12:35:51
|
In message <115...@sp...>
Dennis Lubert <pla...@pr...> wrote:
> Am Mittwoch, den 13.09.2006, 10:13 +0100 schrieb Tom Hughes:
>
>> On recent linux systems fork is actually done with clone so you do
>> have the situation I described.
>>
>> Unfortunately --trace-children is not going to help you.
>>
>> The problem is that valgrind can't really untangle itself from an
>> existing process, so it is only on an exec (when the process image
>> in memory is completely replace) that we can remove ourselves.
>
> Can't V fork() itself and then exec the program that its running? Or
> something like that?
If the client program didn't mind losing all the state it had in
memory then yes, it could. I rather suspect it will mind though.
Don't forget that a fork creates an exact clone of the process at
that point in time, complete with any data structures it has built
in dynamically allocated memory, any file descriptors it has open
and so on.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|