OSX doesn't have objdump, add otool support. about gperftools

[GoogleCodeExporter]

This is actually happening because jags is a bourne shell script, which calls 
lots of
profilable code.  The file_type in ConfigureObjTools doesn't detect that the OS 
is
OSX.  A brute force fix is just taking (line 3402)

$obj_tool_map{"otool"} = "otool";

outside the if statement.  The ultimate solution is to detect the type 
differently.

Original comment by [email protected] on 21 Jun 2009 at 7:34

[GoogleCodeExporter]

You can only profile executables, not shell scripts.  I'm not sure what command 
you
ran to create the profile (jags.pprof), but it's only going to be the profile 
from
one executable that your shell script wrote (probably the last one).  You could 
run
pprof on that last executable, or change your shell script to set CPUPROFILE (or
whatever envvar is appropriate for you) to a different value for each 
executable you
run, and then call pprof on each executable separately.

When you do your brute-force fix, and run pprof, what happens?  I would expect 
otool
to give no output, but I admit I don't really know the tool.

Original comment by [email protected] on 21 Jun 2009 at 7:39

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

[GoogleCodeExporter]

The shell script just sets lots of other environmental variables, so you are 
right,
all I need to do is call the pprof command using the actual executable I called
within the shell script.

There remains one bug though.  OSX does not have addr2line.  I believe "atos" 
is the
OSX equivalent.  After running pprof the first four lines of output are:

sh: addr2line: command not found
sh: addr2line: command not found
sh: addr2line: command not found
sh: addr2line: command not found

Most of the top20 output looks okay, but there are a fair amount of addresses:

      69  14.3%  14.3%      241  49.8% LogicalNode::deterministicSample
      50  10.3%  24.6%       54  11.2% ScalarFunc::checkParameterValue
      44   9.1%  33.7%       44   9.1% Node::value
      42   8.7%  42.4%      123  25.4% ScalarFunc::evaluate
      22   4.5%  46.9%      270  55.8% Sampler::setValue
      20   4.1%  51.0%       20   4.1% 0x0003eb3c
      19   3.9%  55.0%       19   3.9% 0x0003eb12
      13   2.7%  57.6%       13   2.7% 0x00173fff
      13   2.7%  60.3%       13   2.7% 0x00185200
      12   2.5%  62.8%       12   2.5% ScalarFunc::checkScalarValue
      10   2.1%  64.9%       10   2.1% 0x00172209
       7   1.4%  66.3%        7   1.4% Node::parents
       7   1.4%  67.8%        7   1.4% 0x00174003
       6   1.2%  69.0%        6   1.2% 0x0018520f
       6   1.2%  70.2%        6   1.2% 0x00173fd9
       6   1.2%  71.5%        6   1.2% 0x0003eb1e
       5   1.0%  72.5%        7   1.4% 0x00173f79
       5   1.0%  73.6%        5   1.0% _write$NOCANCEL$UNIX2003
       5   1.0%  74.6%        5   1.0% _writev$UNIX2003
       4   0.8%  75.4%        4   0.8% 0x0003ffc1
       4   0.8%  76.2%        4   0.8% 0x0003ffc7

Original comment by [email protected] on 21 Jun 2009 at 8:07

[GoogleCodeExporter]

It looks like atos just does the symbol to function mapping (what we're doing
manually via otool) -- it doesn't show line numbers.  If it does, I didn't see 
a flag
to do so.  Can you give an example usage?

The addresses in your function are probably from libc, or some other library 
that
doesn't have debug symbols.  I don't think it's possible to turn those into 
function
names, in general.

Original comment by [email protected] on 22 Jun 2009 at 4:08