Addresses not mapped to names

GoogleCodeExporter commented 9 years ago

My output is full of addresses. Shouldn't those addresses be resolved? At least 
to a module?

    36.3  36.0%  36.0%     36.3  36.0% 00007f56e83efbe2
    19.3  19.1%  55.0%     19.3  19.1% std::basic_string::_Rep::_S_create
    18.3  18.1%  73.1%     21.3  21.1% _ZN5boost9unordered6detail10table_implINS1_3mapISaISt4pairIKSsN7Cserver9t_torrentEEESsNS_4hashISsEESt8equal_toISsEEEEixERS5_.constprop.838
    16.5  16.4%  89.5%     70.9  70.3% Cserver::read_db_users
    10.5  10.4%  99.9%     10.5  10.4% boost::unordered::detail::buckets::create_buckets
     0.1   0.1% 100.0%      0.1   0.1% 00007f56e83eff89
     0.0   0.0% 100.0%      0.0   0.0% on_exit
     0.0   0.0% 100.0%      0.0   0.0% _ZNSt8_Rb_treeISsSt4pairIKSsN12Cconfig_base11t_attributeISsEEESt10_Select1stIS5_ESt4lessISsESaIS5_EE10_M_insert_EPKSt18_Rb_tree_node_baseSE_RKS5_.constprop.165
     0.0   0.0% 100.0%      0.0   0.0% _ZNSt8_Rb_treeISsSt4pairIKSsN12Cconfig_base11t_attributeIbEEESt10_Select1stIS5_ESt4lessISsESaIS5_EE10_M_insert_EPKSt18_Rb_tree_node_baseSE_RKS5_.constprop.168
     0.0   0.0% 100.0%      0.0   0.0% _dl_rtld_di_serinfo
     0.0   0.0% 100.0%      0.0   0.0% getservbyname
     0.0   0.0% 100.0%      0.0   0.0% __nss_lookup_function
     0.0   0.0% 100.0%      0.0   0.0% _ZNSt8_Rb_treeISsSt4pairIKSsN12Cconfig_base11t_attributeIiEEESt10_Select1stIS5_ESt4lessISsESaIS5_EE10_M_insert_EPKSt18_Rb_tree_node_baseSE_RKS5_.constprop.170
     0.0   0.0% 100.0%      0.0   0.0% _ZNSt8_Rb_treeISsSt4pairIKSsSsESt10_Select1stIS2_ESt4lessISsESaIS2_EE10_M_insert_EPKSt18_Rb_tree_node_baseSB_RKS2_.constprop.62
     0.0   0.0% 100.0%      0.0   0.0% __nss_database_lookup
     0.0   0.0% 100.0%      0.0   0.0% _dl_allocate_tls
     0.0   0.0% 100.0%    100.7  99.9% Cserver::run
     0.0   0.0% 100.0%      0.0   0.0% 00007f56e83f157f
     0.0   0.0% 100.0%      0.0   0.0% boost::make_shared
     0.0   0.0% 100.0%      0.0   0.0% _dl_debug_state
     0.0   0.0% 100.0%      0.0   0.0% std::_Rb_tree::_M_copy
     0.0   0.0% 100.0%      0.0   0.0% tsearch
     0.0   0.0% 100.0%      0.0   0.0% GLIBC_2.2.5
     0.0   0.0% 100.0%      0.0   0.0% std::_Rb_tree::_M_insert_unique
     0.0   0.0% 100.0%     36.2  35.9% Cdatabase::query
     0.0   0.0% 100.0%      0.0   0.0% 00007f56e83cefdc
     0.0   0.0% 100.0%      0.0   0.0% 00007f56e83cefe3
     0.0   0.0% 100.0%      0.0   0.0% 00007f56e83cf038
     0.0   0.0% 100.0%      0.0   0.0% 00007f56e83d2ca7

Original issue reported on code.google.com by olafvdspek on 8 Mar 2012 at 7:04

GoogleCodeExporter commented 9 years ago

The addresses may be from libraries that were built without preserving symbol 
information. Try rebuilding with the '-g' flag set. If the issue still persists 
then the symbols are likely from third party libraries for which symbols have 
been stripped.

Original comment by chapp...@gmail.com on 3 May 2012 at 2:48

GoogleCodeExporter commented 9 years ago

Would it be possible to show the module name in that case?

Original comment by olafvdspek on 3 May 2012 at 2:50

GoogleCodeExporter commented 9 years ago

I don't think that it is possible to show the module name in that case.

Original comment by chapp...@gmail.com on 4 May 2012 at 12:47

GoogleCodeExporter commented 9 years ago

Why not?

Original comment by olafvdspek on 4 May 2012 at 1:03

GoogleCodeExporter commented 9 years ago

Actually that comment was a bit short sighted. I suppose that pprof can attempt 
to match the symbol address to the corresponding module listed in 
MAPPED_LIBRARIES in the event that the usual means fail to resolve to a symbol 
(i.e. nm fails). May take a bit of perl expertise to make this happen :). If 
you feel up to the challenge you are more than welcome to put together a patch.

Original comment by chapp...@gmail.com on 4 May 2012 at 5:39

cynthia / gperftools

Addresses not mapped to names #415