cpython - gperftools failing to identify files -

is there way avoid google performance tools listing files "??:?", is, failing locate file contains function reporting on? how can work out library contains function being called?

$ env ld_preload="/usr/lib/libprofiler.so.0" \    cpuprofile=output.prof python script.py $ google-pprof --text --files /usr/bin/python output.prof  using local file /usr/bin/python. using local file output.prof. removing _l_unlock_13 stack traces. total: 433 samples  362  83.6%  83.6%      362  83.6% dtrsm_ ??:?   58  13.4%  97.0%       58  13.4% dgemm_ ??:?    1   0.2%  97.2%        1   0.2% pydict_getitem /.../objects/dictobject.c    1   0.2%  97.5%        1   0.2% pyparser_addtoken /.../parser/parser.c ... 

i aiming able profile c code in python package has many compiled c extension modules. in toy example above, track down "dtrsm_" defined? if there multiple loaded libraries contain functions same name, there way tell version being called?

c/c++ won't compile if same pre-processed sourcefile (e.g. #includes expanded) contains duplicate definitions same symbol. (note in case of c++, symbols mangled, according compiler-specific schemes, incorporate argument signature facilitate overloaded functions, not otherwise differentiated.)

the linker concerned unresolved symbols (so there ought nothings preventing multiple libraries concurrently calling own respective internally-defined functions coincident names). if file invokes declared undefined function, , multiple available libraries implement symbol, linker free choose (say precedence in search-path) version gets substituted in. (incidentally, same mechanism profilers such gperftools or hpctoolkit able inject , alter normal behaviour of application.)

since different libraries mapped separate pages of memory, ought possible identify (from memory addresses) library contains executing version of function. indeed, gnu debugger can identify library code contained by, when fails name function.

$      gdb python (gdb)  run -c "from numpy import *; linalg.inv(random.random((1000,1000)))" ctrl-c (gdb)  backtrace #0 0x00007ffff5ba9df8 in dtrsm_ () /usr/lib/libblas.so.3 ... #3 0x00007ffff420df83 in ?? () /.../numpy/linalg/_umath_linalg.so 

linux (or rather gnu c library) provides "backtrace" call (for getting list of pointers call stack), , "backtrace_symbols" call automatically converting each of pointers descriptive string such as:

"/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7fc429929ec5]" 

gperftools can (judging query on github mirror) call generic "backtrace", instead of "backtrace_symbols" "forks out pprof actual symbolizing". fairly-epic perl script, , looks "??" comes from.

crucially, google-pprof trying report on source-file (and line-number) defines function, not binary-file containing machine-code (that typically quoted in stack traces). invokes "nm" utility. on system appears (by running "nm -l -d") libblas, unlike libc , python binary, has been stripped of such debugging symbols (presumably optimisation), explaining result.

to answer original question: call-stack samples should definitively , explicitly specify version being called. these can dumped using option added in google-pprof several months ago, or (for time-intensive functions) can ascertained manual resampling using gdb. (it's conceivable g-pprof can adjusted explicitly identify binaries paths in output summaries.) alternatively 1 can run "nm" (and grep) on candidate binaries/libraries (of short-list can obtained running "strings" on profiler's raw output, among other methods). if source accessible (to grep) or libraries popular (on web) of course (and per mike dunlavey) may easiest query function name. in theory "??:?" may addressed recompiling offending objects.