koolhazz / gperftools

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

No nodes to print #624

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Compiled my server setting ProfilerStart() and ProfilerStop() in respective 
functions.
2. Set CPUPROFILE=<absoule prof file path>
3. started server and ran for 1 hour.
4. Though server was running for significant time, prof file generated was of 
size around 7kb. The file size never changed since the start of server
5. Killed the server. 
6. On using pprof to analyze data it shows message "No nodes to print"

When I try to profile any program which end successfully from "main()" 
function, the prof file generates valid report. 

However, this time I want to profile a server, which runs continuously and 
hence never returns from "main()". 

How to generate valid prof file in this scenario?

Thanks for help in advance.

Original issue reported on code.google.com by gaurav...@gmail.com on 27 May 2014 at 4:20

GoogleCodeExporter commented 9 years ago
You're probably experiencing 
https://code.google.com/p/gperftools/issues/detail?id=335

Original comment by alkondratenko on 27 May 2014 at 7:28

GoogleCodeExporter commented 9 years ago
Thanks for a quick reply.

The scenario in the attachment is bit different than me. When I write a sample 
code that returns from main function profiling works perfectly.

However, I am trying to profile a server in which code execution never reach to 
the end of "main()" function. The server runs continuously spawning threads. 

Do we have to implement something like signal handler to hand kill signal to 
flush the profiler data?

Original comment by gaurav...@gmail.com on 28 May 2014 at 6:27

GoogleCodeExporter commented 9 years ago
I don't think you need to do anything special to hand-flush profiler data. Are 
you really sure you're not being affected by "gperftools profiler only profiles 
main thread by default" ? You mention threads and unless you register all of 
them via ProfilerRegisterThread you should be affected by that issue.

Original comment by alkondratenko on 28 May 2014 at 5:13

GoogleCodeExporter commented 9 years ago
Indeed your case is different. ProfilerFlush seems to be the call you need.

Original comment by alkondratenko on 5 Aug 2014 at 6:26

GoogleCodeExporter commented 9 years ago
Assuming it's ProfilerFlush that you needed here. Sorry for confusion.

Original comment by alkondratenko on 5 Aug 2014 at 6:48