When I use oprofile tool for performance analysis, the result include many stats of stl function, ACE function and boost function, how can i exclude these libraries when use oprofile for statistics?
This is my result:
samples cum. samples % cum. % symbol name
13935 13935 15.8646 15.8646 std::less<unsigned int>::operator()(unsigned int const&, unsigned int const&) const
5552 19487 6.3208 22.1854 cache_result::decode(void*, unsigned long&, void const*, unsigned long)
5360 24847 6.1022 28.2876 cache::CWebCachePolicy::makexmlReply(cache::CCacheQueuedRequest*, iovec&, ACE_5_6_1::ACE_Message_Block*)
4661 29508 5.3064 33.5940 std::_Rb_tree<unsigned int, unsigned int, std::_Identity<unsigned int>, std::less<unsigned int>, std::allocator<unsigned int> >::_S_key(std::_Rb_tree_node<unsigned int> const*)
4649 34157 5.2928 38.8868 cache::CWebCachePolicy::updateOneSummaryResult(cache::CCacheQueuedRequest*, char*, int, int&, int*, int*, int*, char (*) [20], int*, int, int)
4568 38725 5.2005 44.0873 std::_Identity<unsigned int>::operator()(unsigned int const&) const
4266 42991 4.8567 48.9441 std::_Rb_tree_const_iterator<unsigned int>::_Rb_tree_const_iterator(std::_Rb_tree_node<unsigned int> const*)
3843 46834 4.3751 53.3192 std::_Rb_tree<unsigned int, unsigned int, std::_Identity<unsigned int>, std::less<unsigned int>, std::allocator<unsigned int> >::_S_value(std::_Rb_tree_node<unsigned int> const*)
3000 49834 3.4154 56.7346 std::_Rb_tree<unsigned int, unsigned int, std::_Identity<unsigned int>, std::less<unsigned int>, std::allocator<unsigned int> >::end() const
The result above shows many stl functions, which I want to do is just take care of my own function, not the standard libraries.
Related
Compile the snippet with clang++ -std=c++17 -g source.cpp
#include <map>
#include <string>
int main()
{
std::map<std::string, int> m;
m["foo"] = 23;
}
Try to access the element with key foo, but have errors:
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x000000010000131e a.out`main at source.cpp:8:3
5 {
6 std::map<std::string, int> m;
7 m["foo"] = 23;
-> 8 }
Target 0: (a.out) stopped.
(lldb) p m["foo"]
error: no viable overloaded operator[] for type 'std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<const std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int> > >'
candidate function not viable: no known conversion from 'const char [4]' to 'const std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<const std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int> > >::key_type' (aka 'const std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >') for 1st argument
candidate function not viable: no known conversion from 'const char [4]' to 'std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<const std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, int> > >::key_type' (aka 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >') for 1st argument
(lldb) p m[std::string("foo")]
error: no member named 'string' in namespace 'std'
(lldb) p m[std::__1::string("foo")]
error: no matching conversion for functional-style cast from 'const char [4]' to 'std::__1::string' (aka 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >')
candidate constructor not viable: no known conversion from 'const char [4]' to 'const std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::allocator_type' (aka 'const std::__1::allocator<char>') for 1st argument
...
candidate constructor not viable: no known conversion from 'const char [4]' to 'std::initializer_list<char>' for 1st argument
candidate constructor not viable: requires 0 arguments, but 1 was provided
...
candidate constructor not viable: requires 4 arguments, but 1 was provided
How to work with string variables in the right way using lldb?
You don't say what versions of clang++ & lldb you are using. Using the tools that ship with Xcode 13, I see:
(lldb) expr m["foo"]
(std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int> > >::mapped_type) $0 = 23
(lldb) expr m[std::string("foo")]
(std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int> > >::mapped_type) $1 = 23
which is clearly not what you are getting. These simple seeming C++ expressions actually end up creating a bunch of templated entities behind the scenes, and reconstructing the information needed to instantiate templates from debug information alone is tricky to impossible.
But there has been a bunch of work done recently on the lldb side to support building the clang module for the C++ standard library from which we can extract the necessary information. Either you have an older lldb which doesn't have this work, or for some reason building the clang module is failing. If you are using a current lldb, then you might want to file a bug with http://bugs.llvm.org and see if somebody can help you figure out what's going wrong.
Note, also, lldb doesn't rely on expression evaluation alone for presentation of the common C++ (or ObjC/Swift) containers. It also has a system of "data formatters" which understand the underlying structure of these container classes and can represent the contents w/o having to call the actual language accessors. By default the results of expressions are formatted using the data formatters (expr --raw -- turns the formatters off). That's why you see:
(lldb) expr m
(std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int> > >) $0 = size=1 {
[0] = (first = "foo", second = 23)
}
rather than all the actual fields of std::map.
In this case, the data formatter for std::map presents the map as a vector of pairs. Since the keys can be anything, this provides a more convenient way to access the elements...
This syntax can't be fed back into the expression evaluator - which is intended to be as close to the source language as possible, but you can use them to dig into local variables using the frame var command - short alias v:
(lldb) v m[0]
(std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int>) [0] = (first = "foo", second = 23)
(lldb) v m[0].first
(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >) m[0].first = "foo"
etc.
I get use-of-uninitialized-value warning while executing the following program compiled with clang++-9 -fsanitize=memory:
#include <map>
class msan_test
{
std::map<int, int> m_map;
public:
msan_test()
{
m_map.insert(std::make_pair(1, 1));
m_map.insert(std::make_pair(2, 2));
}
};
msan_test gobj; // global object of above class
int main()
{
return 0;
}
This is the warning I get:
==16598==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x49898f in std::_Rb_tree<int, std::pair<int const, int>, std::_Select1st<std::pair<int const, int> >, std::less<int>, std::allocator<std::pair<int const, int> > >::_M_get_insert_unique_pos(int const&) (/home/noname/a.out+0x49898f)
#1 0x49828e in std::pair<std::_Rb_tree_iterator<std::pair<int const, int> >, bool> std::_Rb_tree<int, std::pair<int const, int>, std::_Select1st<std::pair<int const, int> >, std::less<int>, std::allocator<std::pair<int const, int> > >::_M_emplace_unique<std::pair<int, int> >(std::pair<int, int>&&) (/home/noname/a.out+0x49828e)
#2 0x497a7e in std::enable_if<is_constructible<std::pair<int const, int>, std::pair<int, int> >::value, std::pair<std::_Rb_tree_iterator<std::pair<int const, int> >, bool> >::type std::map<int, int, std::less<int>, std::allocator<std::pair<int const, int> > >::insert<std::pair<int, int> >(std::pair<int, int>&&) (/home/noname/a.out+0x497a7e)
#3 0x49785a in msan_test::msan_test() (/home/noname/a.out+0x49785a)
#4 0x41be52 in __cxx_global_var_init (/home/noname/a.out+0x41be52)
#5 0x41beb8 in _GLOBAL__sub_I_memsan.cpp (/home/noname/a.out+0x41beb8)
#6 0x49bcbc in __libc_csu_init (/home/noname/a.out+0x49bcbc)
#7 0x7f5db517db27 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:266
#8 0x41bee9 in _start (/home/noname/a.out+0x41bee9)
SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/noname/a.out+0x49898f) in std::_Rb_tree<int, std::pair<int const, int>, std::_Select1st<std::pair<int const, int> >, std::less<int>, std::allocator<std::pair<int const, int> > >::_M_get_insert_unique_pos(int const&)
Exiting
Is this a false positive or something deep is going on?
Thanks.
This is probably already reported MemorySanitizer bug https://github.com/google/sanitizers/issues/542.
However it was closed with Status WontFix without much explanation.
It seems that you need to build instrumented C++ standard library to avoid false positives. From MemorySanitizer wiki:
If you want MemorySanitizer to work properly and not produce any false
positives, you must ensure that all the code in your program and in
libraries it uses is instrumented (i.e. built with -fsanitize=memory).
In particular, you would need to link against MSan-instrumented C++
standard library. We recommend to use libc++ for that purpose.
Is this a false positive or something deep is going on?
Either this is false positive in the sanitiser, or the standard library implementation has a bug.
There is no reading of uninitialised value in the shown program.
I run sudo valgrind --leak-check=full -v --track-origins=yes ./myprogram
The result is:
==31734== 1 errors in context 7 of 7:
==31734== Conditional jump or move depends on uninitialised value(s)
==31734== at 0x61CCCC: TlsProtocol::sendRecord(unsigned char const*, unsigned int, int, int, int, TlsEndpoint&, unsigned int, SocketParams&, LogBase&) (in /home/me/src/myprogram)
==31734== by 0x61D32E: TlsProtocol::sendHandshakeMessages(DataBuffer&, int, int, TlsEndpoint&, unsigned int, SocketParams&, LogBase&) (in /home/me/src/myprogram)
==31734== by 0x620B1C: TlsProtocol::sendClientHello(TlsEndpoint&, unsigned int, SocketParams&, LogBase&) (in /home/me/src/myprogram)
==31734== by 0x6265E7: TlsProtocol::clientHandshake2(TlsEndpoint&, unsigned int, SocketParams&, LogBase&) (in /home/me/src/myprogram)
==31734== by 0x627789: TlsProtocol::clientHandshake(char const*, int, TlsEndpoint&, unsigned int, SocketParams&, SharedCertChain*, LogBase&) (in /home/me/src/myprogram)
==31734== by 0x616855: SChannelChilkat::connectImplicitSsl(char const*, int, bool, int, unsigned int, unsigned int, SystemCerts&, SocketParams&, LogBase&, bool&, SharedCertChain*) (in /home/me/src/myprogram)
==31734== by 0x56DDEB: Socket2::connect2(char const*, int, bool, bool, int, SystemCerts&, unsigned int, unsigned int, SocketParams&, LogBase&, bool&, int&, SharedCertChain*) (in /home/me/src/myprogram)
==31734== by 0x56E24F: Socket2::socket2Connect(char const*, int, bool, bool, int, SystemCerts&, unsigned int, unsigned int, SocketParams&, LogBase&, bool&, int&, SharedCertChain*, ClsSocksClient&, ClsHttpProxyClient*) (in /home/me/src/myprogram)
==31734== by 0x514FD9: Imap::connectToImapServer(char const*, int, StringBuffer&, SharedCertChain*, SystemCerts&, ClsSocksClient&, ClsHttpProxyClient*, LogBase&, ProgressMonitor*) (in /home/me/src/myprogram)
==31734== by 0x48BB69: ClsImap::Connect(XString&, ProgressEvent*) (in /home/me/src/myprogram)
==31734== by 0x454A5D: CkImap::Connect(char const*) (in /home/me/src/myprogram)
==31734== by 0x422C2E: EmailSensorAlertConnection::Connect(char const*, int, bool, char const*, char const*) (emailconnection.cpp:150)
==31734== Uninitialised value was created by a heap allocation
==31734== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31734== by 0x47F219: ClsImap::createNewCls() (in /home/me/src/myprogram)
==31734== by 0x4567EA: CkImap::CkImap() (in /home/me/src/myprogram)
==31734== by 0x422A13: EmailConnection::EmailConnection(std::string) (emailconnection.cpp:110)
==31734== by 0x41D364: IMAPConnectionFactory::getIMAPConnection() (imapconnectionfactory.cpp:46)
==31734== by 0x431362: main (myprogram.cpp:348)
==31734==
==31734== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)
Part of myprogram.cpp is:
bool connectRes = m_imap.Connect( server );//line 348
I try to find the uninitialized variable. It seems that it is in:ClsImap::createNewCls(). I used grep to search this function. This function is in libchilkat-e/lib/libchilkat-9.5.0.a. How to fix this problem? It seems that the problem is in the lib. So I can do nothing? Am I right?
I am new to valgrind, so this could be missintepreting the output.
Valgrind seems to think bytes are being lost in the following lines:
if ( mysqlpp::StoreQueryResult result = query.store() ){
for ( size_t i = 0; i < result.num_rows(); ++i ){
hash = std::string( result[i]["hash"].data(), result[i]["hash"].length() );
label = std::string( result[i]["label"].data(), result[i]["label"].length() );
keywords = std::string( result[i]["keywords"].data(), result[i]["keywords"].length() );
task_raw = std::string( result[i]["task"].data(), result[i]["task"].length() );
solution_raw = std::string( result[i]["solution"].data(), result[i]["solution"].length() );
In fact it complains every time there is an std::string being constructed this way^^. I cannot figure out if this is a false-positive, if the way I'm copying is not the right way, or if the result is being leaked somehow.
Interestingly enough, it complains about another piece of code that doesn't use mysql++, but again a string constructor is used:
for ( auto & f : frames ){
for ( unsigned int i = 0; i < f.getTask().size(); i++ ){
if ( i + 1 < f.getTask().size() ){
auto t = f.getTask()[i].value();
auto n = f.getTask()[i+1].value();
pairs.push_back( std::string( t + n ) );
The line where a string is being constructed and pushed back, are possibly lost. Then a detailed output of malloc, operator new, std::string, etc are given.
The same story appears again, when copying a string from a std::istringstream:
std::copy( std::istream_iterator<std::string>(iss), std::istream_iterator<std::string>(), std::back_inserter<std::vector<std::string> >(tokens));
Are those false-positives? Does it have to do with using C++0x? Or are those legit leaks that may be originating from somewhere I have not yet detected to be leaking?
EDIT
Below is a sample of the reoccurring valgrind warning:
==18141== 9,555 bytes in 147 blocks are possibly lost in loss record 250 of 256
==18141== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==18141== by 0x7CA74C: operator new(unsigned long) (in trunk/Build/icarus)
==18141== by 0x7B4208: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /trunk/Build/icarus)
==18141== by 0x7B5904: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in trunk/Build/icarus)
==18141== by 0x7B5A7C: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, unsigned long, std::allocator<char> const&) (in trunk/Build/icarus)
==18141== by 0x610D65: Frame::mySQLloadFrameFromExample(std::string const&) (Frame.cpp:80)
==18141== by 0x6103FB: Frame::Frame(std::string const&) (Frame.cpp:5)
==18141== by 0x6054DB: Domain::mySQLloadFrames() (Domain.cpp:90)
==18141== by 0x60489D: Domain::Domain(std::string) (Domain.cpp:7)
==18141== by 0x628876: DomainController::loadDomainData() (DomainController.cpp:33)
==18141== by 0x628582: DomainController::DomainController() (DomainController.cpp:5)
==18141== by 0x627002: Controller::Controller() (Controller.cpp:26)
They are almost all identical, with the only difference being the actual line in code (i.e: the string constructor line).
The second type of warning is:
==18141== 3,562 bytes in 137 blocks are possibly lost in loss record 242 of 256
==18141== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==18141== by 0x7CA74C: operator new(unsigned long) (in trunk/Build/icarus)
==18141== by 0x7B4208: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in trunk/Build/icarus)
==18141== by 0x7B4EFA: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (in trunk/Build/icarus)
==18141== by 0x7B4FDF: std::string::reserve(unsigned long) (in trunk/Build/icarus)
==18141== by 0x784F2F: std::basic_istream<char, std::char_traits<char> >& std::operator>><char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (in trunk/Build/icarus)
==18141== by 0x61208E: std::istream_iterator<std::string, char, std::char_traits<char>, long>::_M_read() (stream_iterator.h:121)
==18141== by 0x613405: std::istream_iterator<std::string, char, std::char_traits<char>, long>::operator++() (stream_iterator.h:95)
==18141== by 0x6131BC: std::back_insert_iterator<std::vector<std::string, std::allocator<std::string> > > std::__copy_move<false, false, std::input_iterator_tag>::__copy_m<std::istream_iterator<std::string, char, std::char_traits<char>, long>, std::back_insert_iterator<std::vector<std::string, std::allocator<std::string> > > >(std::istream_iterator<std::string, char, std::char_traits<char>, long>, std::istream_iterator<std::string, char, std::char_traits<char>, long>, std::back_insert_iterator<std::vector<std::string, std::allocator<std::string> > >) (stl_algobase.h:298)
==18141== by 0x612D09: std::back_insert_iterator<std::vector<std::string, std::allocator<std::string> > > std::__copy_move_a<false, std::istream_iterator<std::string, char, std::char_traits<char>, long>, std::back_insert_iterator<std::vector<std::string, std::allocator<std::string> > > >(std::istream_iterator<std::string, char, std::char_traits<char>, long>, std::istream_iterator<std::string, char, std::char_traits<char>, long>, std::back_insert_iterator<std::vector<std::string, std::allocator<std::string> > >) (stl_algobase.h:384)
==18141== by 0x6121FD: std::back_insert_iterator<std::vector<std::string, std::allocator<std::string> > > std::__copy_move_a2<false, std::istream_iterator<std::string, char, std::char_traits<char>, long>, std::back_insert_iterator<std::vector<std::string, std::allocator<std::string> > > >(std::istream_iterator<std::string, char, std::char_traits<char>, long>, std::istream_iterator<std::string, char, std::char_traits<char>, long>, std::back_insert_iterator<std::vector<std::string, std::allocator<std::string> > >) (stl_algobase.h:422)
==18141== by 0x611C6A: std::back_insert_iterator<std::vector<std::string, std::allocator<std::string> > > std::copy<std::istream_iterator<std::string, char, std::char_traits<char>, long>, std::back_insert_iterator<std::vector<std::string, std::allocator<std::string> > > >(std::istream_iterator<std::string, char, std::char_traits<char>, long>, std::istream_iterator<std::string, char, std::char_traits<char>, long>, std::back_insert_iterator<std::vector<std::string, std::allocator<std::string> > >) (stl_algobase.h:454)
Which seems to be related with the std::istringstream code mentioned above.
I'm getting helgrind errors using asio::ip::tcp::socket::async_connect while at the same time io_service::run is running in a thread pool. The reports is:
Possible data race during read of size 8 at 0x507bb50 by thread #6
==13316== at 0xDDF1CC: boost::asio::detail::epoll_reactor::descriptor_state::perform_io(unsigned int) (epoll_reactor.ipp:610)
==13316== by 0xDDF355: boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) (epoll_reactor.ipp:648)
==13316== by 0xD7CF93: boost::asio::detail::task_io_service_operation::complete(boost::asio::detail::task_io_service&, boost::system::error_code const&, unsigned long) (task_io_service_operation.hpp:37)
==13316== by 0xE17469: boost::asio::detail::task_io_service::do_run_one(boost::asio::detail::scoped_lock&, boost::asio::detail::task_io_service::thread_info&, boost::asio::detail::op_queue&, boost::system::error_code const&) (task_io_service.ipp:394)
==13316== by 0xE1713B: boost::asio::detail::task_io_service::run(boost::system::error_code&) (task_io_service.ipp:146)
==13316== by 0xE176FC: boost::asio::io_service::run() (io_service.ipp:59)
==13316== by 0xF97421: Common::ServiceRunner::ServiceThread() (ServiceRunner.cpp:67)
....
This conflicts with a previous write of size 8 by thread #9
==13316== at 0xDDE5EF: boost::asio::detail::epoll_reactor::register_descriptor(int, boost::asio::detail::epoll_reactor::descriptor_state*&) (epoll_reactor.ipp:156)
==13316== by 0xE75C34: boost::asio::detail::reactive_socket_service_base::do_open(boost::asio::detail::reactive_socket_service_base::base_implementation_type&, int, int, int, boost::system::error_code&) (reactive_socket_service_base.ipp:152)
==13316== by 0xE7B6E2: boost::asio::detail::reactive_socket_service::open(boost::asio::detail::reactive_socket_service::implementation_type&, boost::asio::ip::tcp const&, boost::system::error_code&) (reactive_socket_service.hpp:106)
==13316== by 0xE79FF7: boost::asio::stream_socket_service::open(boost::asio::detail::reactive_socket_service::implementation_type&, boost::asio::ip::tcp const&, boost::system::error_code&) (stream_socket_service.hpp:127)
==13316== by 0xE78904: void boost::asio::basic_socket >::async_connect >, boost::_bi::list3 >, boost::arg<1> (*)(), boost::_bi::value > > > > >(boost::asio::ip::basic_endpoint const&, boost::asio::detail::wrapped_handler >, boost::_bi::list3 >, boost::arg<1> (*)(), boost::_bi::value > > > > const&) (basic_socket.hpp:712)
==13316== by 0xE7376B: Common::Comms::TCPClient::HandleResolve(boost::system::error_code const&, boost::asio::ip::basic_resolver_iterator) (TCPClient.cpp:297)
*I found that async_connect is not real problem, but opening a socket is, when io_service::run is running.*
thanks in advance for your help