CPU profiler does not work on FreeBSD 6.0 on multi-threaded programs

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Wrote a simple multi-threaded program 
2. Enabled CPU profiling

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

Everything works fine until the first pthread_create() call. After that the 
timer stops counting down and the process no longer receives the SIGPROF 
signal. 

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

perftools-1.3 on FreeBSD 6.0 i386

Please provide any additional information below.

We think this problem could be due to this defect in the FreeBSD 6.0 
kernel. 

http://markmail.org/message/ds2lxujkpbj45woa

Has anybody else encountered the same issue?

Original issue reported on code.google.com by ritesh1...@gmail.com on 17 Jul 2009 at 9:28

[GoogleCodeExporter]

Yes!  I've seen this issue too.  In fact, I even mention it on the release 
notes for
perftools-1.2 (at http://code.google.com/p/google-perftools/).  Most perftools
unittests pass, but some fail.  I thought perftools worked in 'real life', but 
it
sounds like maybe not.

If you can figure out what the problem is, or how to work around it, that would 
be great!

Original comment by csilv...@gmail.com on 17 Jul 2009 at 9:48

• Changed state: Accepted
• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

I have similar problem with pthread programs on Linux

Original comment by qun...@gmail.com on 9 Feb 2010 at 1:03

[GoogleCodeExporter]

} I have similar problem with pthread programs on Linux

Under which version of perftools?  What is the exact problem you're seeing?

Original comment by csilv...@gmail.com on 9 Feb 2010 at 1:16

[GoogleCodeExporter]

I also meet this problems too, and I have found a way to fix it.
My Linux is Red Hat Enterprise Linux 4. 

[admin@121 loadtest]$ uname -a
Linux 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 x86_64 x86_64 
GNU/Linux

I attached the sample, and the fix for it.

The key is run the program with addtional lib

LD_LIBRARY_PATH=/home/admin/google-perftools/lib LD_PRELOAD=./gprof-helper.so 
CPUPROFILE=test.prof ./testThreadGoogle 

You can download the gprof-helper.c from 
http://sam.zoy.org/writings/programming/gprof.html
Just compile the gprof-helper.c to gprof-helper.so

Original comment by yehuijun...@gmail.com on 4 Nov 2010 at 5:06

Attachments:

• test.cpp

[GoogleCodeExporter]

I try another way to fix the pthread problem.

I insert the code in my demo case as the perf tools document introduced.

It works fine for multithread programs. 

I have attached the program.

Original comment by yehuijun...@gmail.com on 5 Nov 2010 at 1:44

Attachments:

• testvar.cpp

[GoogleCodeExporter]

yehuijun2001, I think your problem is different from the one for this bug 
report, which is specific to freebsd 6.0.  In theory, this should all Just Work 
for you, with a 2.6.9 kernel.  I'm a bit surprised to see you needed 
ProfilerRegisterThread, but I'm glad it works for you.

It should be possible to combine this with the technique from the gprof.html 
page you point to: provide your own definition of pthread_create() which spawns 
a new thread and then calls ProfilerRegisterThread in it.  Usually that's 
overkill, though.

Original comment by csilv...@gmail.com on 9 Nov 2010 at 3:58

[GoogleCodeExporter]

I have exactly the same issue with RedHat_x86_64, kernel 
2.6.9-89.ELsmp/perftools-1.6

I use ProfilerStart/ProfilerStop API to start and stop profiling, but only main 
thread gets profiled. ProfilerRegisterThread function helped me, but I can't 
modify original source code, so it's not a solution for me. LD_PRELOAD also not 
acceptable. 

Is this a bug in CPU profiler? 
Is there a way to profile all threads without ProfilerRegisterThread and 
pthread wrapper?

Original comment by pavl...@gmail.com on 19 May 2011 at 12:07

[GoogleCodeExporter]

The symptoms may be the same, but the bug is different -- the bug we're talking 
about here is specific to freebsd kernels.  There really should be a separate 
bug for this.  That said, does yehuijun2001's fix in comment 6 work for you?

Original comment by csilv...@gmail.com on 19 May 2011 at 12:52

[GoogleCodeExporter]

I tried yehuijun2001's fix, it doesn't work for me, still the same results. 
I have created a small test case, will submit as a separate issue.

Original comment by pavl...@gmail.com on 19 May 2011 at 6:09

[GoogleCodeExporter]

I seem to recall running the cpu profiler on freebsd with programs compiled 
with lthr and not having any issues. It is possible that I also may have been 
using freebsd8 and not freebsd6. I wouldn't mind digging into this one a bit 
further for you guys but I will need to setup vmware running freebsd. 

Original comment by chapp...@gmail.com on 12 Oct 2011 at 2:37

[GoogleCodeExporter]

It would be great if you wanted to figure this out!  It's been a longstanding 
bug that at least it would be nice to know the cause of.  If it's 
freebsd6-specific it probably doesn't matter anymore.  That said, I do have a 
freebsd8 machine to test on, and I recall that we still see problems there.  
'make check' should show the failure; I don't know if that uses -lthr or not.

Original comment by csilv...@gmail.com on 12 Oct 2011 at 6:30

[GoogleCodeExporter]

Kind of forgot about this one. I now have a suitable install of FreeBSD6 
running that I can use to look into this further.

Original comment by chapp...@gmail.com on 2 Mar 2012 at 6:35

[GoogleCodeExporter]

I reported this problem back in 2009. Just want to let everybody know that CPU 
profiler works fine from FreeBSD 7.2 onwards. Haven't tried on FreeBSD 7.0/7.1 
but may work in those releases as well.

Original comment by ritesh.s...@gmail.com on 5 Apr 2012 at 5:06

[GoogleCodeExporter]

As a final comment here, I have had success running this on FreeBSD 6.0 using 
libthr instead of libpthread. You can give that a try if you run into this 
issue. However, since FreeBSD 6.0 is a bit dated and most people should have 
moved on to 7.0 or 8.0 at this point, I am going to close of this issue.

Original comment by chapp...@gmail.com on 21 Apr 2012 at 5:59

• Changed state: WontFix