search

casseopea2 / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
1 stars 0 forks source link

Profiling does not happen across fork() calls #104

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Start a program linked with the google perftools libraries.
2. Have the program fork() a child and let the parent process exit.
3. Have the child process profile some piece of code by calling 
ProfilerStart().

What is the expected output? What do you see instead?

The expected output is that profile data should be produced. However, in 
reality, no profiles will be produced. This is because the periodic SIGPROF 
alarm generated by the call to setitimer() is not inherited across fork() 
system calls.

What version of the product are you using? On what operating system?

Version 1.0. Linux 2.6.27.

Please provide any additional information below.

One fix might be to use pthread_atfork() call inside 
CpuProfiler::CpuProfiler() in profiler.cc. The pthread_atfork() can ensure 
that ProfilerRegisterThread() is called immediately upon forking a new 
child process.

Original issue reported on code.google.com by mohit.a...@gmail.com on 5 Feb 2009 at 7:31

GoogleCodeExporter commented 9 years ago

Original comment by csilv...@gmail.com on 6 Feb 2009 at 3:12

GoogleCodeExporter commented 9 years ago

Original comment by csilv...@gmail.com on 6 Feb 2009 at 3:13

GoogleCodeExporter commented 9 years ago 
Issue 104 has been merged into this issue.

Original comment by csilv...@gmail.com on 11 Mar 2009 at 9:05

GoogleCodeExporter commented 9 years ago 
You are right that cpu profiling does not work across forks, unless the child 
process
immediately calls exec (and thus gets its own timer that way).  I agree
pthread_atfork needs to be part of any solution.  However, there are other 
issues as
well, to make sure that the child process does not corrupt the parent's profile
information.

We started working on a fix, which I had hoped to have ready for perftools 1.1, 
but
it's turned out to be more complicated than I had hoped -- one issue is that
perftools is designed to work properly even when pthreads is not linked in -- 
so it
looks like this will slip until perftools 1.2. :-(  On the plus side, I'm 
hoping the
extra time will let us work on a solution that does not require any user 
intervention
at all to work properly.

In the meantime, I've updated the README to document the problem.

Original comment by csilv...@gmail.com on 11 Mar 2009 at 9:09

GoogleCodeExporter commented 9 years ago 
I know we made some changes to the profiler recently to deal with forks, but I 
don't
think we fixed this particular issue.  Can you confirm it's still a problem with
perftools 1.4, just released?  If so, how high a priority is this bug for you?

Original comment by csilv...@gmail.com on 11 Sep 2009 at 6:44

GoogleCodeExporter commented 9 years ago 
I would just like to confirm that this issue is still present in v1.4, tested 
on Linux 2.6.24 with the same results as 
the submitter.

Original comment by benjamin...@gmail.com on 4 Nov 2009 at 10:21

GoogleCodeExporter commented 9 years ago 
Craig, is this fixed in v1.5 ? I am facing this problem. I call fork() without 
an exec().

Original comment by ashwi...@gmail.com on 22 Jul 2010 at 6:52

GoogleCodeExporter commented 9 years ago 
No, I'm sorry, it still hasn't been fixed.  I'm not really equipped to fix 
this, since I don't understand the ins and outs of pthreads well enough, and 
the folks I had recruited back at perftools 1.1 have drifted off to other 
efforts.  I've lowered the priority in my head (though not on the bug report) 
because I feel fork without exec is pretty uncommon, so this wouldn't be that 
useful a feature.  Perhaps that's incorrect?

If anyone would like to submit a patch to fix this up, that would definitely 
help speed the process along! :-)

Original comment by csilv...@gmail.com on 22 Jul 2010 at 1:53

GoogleCodeExporter commented 9 years ago 
I fork inside a very large application to be more memory efficient.  When one 
process takes 20GB, it's best to share as much as possible.  This capability 
would be very useful.

Original comment by ross...@gmail.com on 27 Jul 2010 at 12:27

GoogleCodeExporter commented 9 years ago 
Ok -- feel free to submit a patch!

Original comment by csilv...@gmail.com on 27 Jul 2010 at 12:41

GoogleCodeExporter commented 9 years ago 
It's been over a year now and I haven't heard anything, so I'm closing this 
WillNotFix.  If anyone is inspired to work on it, I'm happy to accept patches.

Original comment by csilv...@gmail.com on 31 Aug 2011 at 10:05

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
It would be lovely to see this limitation more prominently documented.  Now 
that I know about this issue, I am exiting forks with exec rather than exit as 
a workaround.  But it would be nice to see this more documented in the caveats 
section of the CPU profiling page.

Original comment by daverou...@gmail.com on 18 Jan 2015 at 10:13

GoogleCodeExporter commented 9 years ago 
Please submit a patch for documentation and I'll gladly accept it.

Original comment by alkondratenko on 19 Jan 2015 at 3:55