Those "leaks" are harmless because they're not really leaks, just memory that is still reachable at program exit. If you really want to make them disappear from the Valgrind output, though, you can try calling google::protobuf::ShutdownProtobufLibrary() (from src/google/protobuf/stubs/common.h) right before your program exits.
On Mon, Oct 21, 2019 at 6:38 AM Boris Pitel <[email protected]> wrote: > Hi fellows, > > I am running an application on Redhat which is linked with protobuf > generated code. But this particular app doesn't use protobuf at all - it is > just linked with library which in its turn linked with protobuf files. > > When I run my app under valgrind it shows many many small leaks. Most of > them originate to call to GoogleOnceInit. > Is it normal ? Can I do something to get rid of this "leaks"? Or at least > may be somebody can suggest how I can suppress this messages so valgrind > report would not look so confusing :) > Here is the one of the stack traces of the leak reported by valgrind. I > have many of similar blocks. > > >>> 978 ==60781== 56 bytes in 1 blocks are still reachable in loss record >>> 48 of 87 >> >> 979 ==60781== at 0x4C2A483: operator new(unsigned long) >>> (vg_replace_malloc.c:344) >> >> 980 ==60781== by 0x835430B: allocate (new_allocator.h:104) >> >> 981 ==60781== by 0x835430B: _M_get_node (stl_tree.h:370) >> >> 982 ==60781== by 0x835430B: _M_create_node<std::pair<const >>> std::basic_string<char, std::char_traits<char>, std::allocator<char> >, >>> std::pair<void cons t*, int> > > (stl_tree.h:403) >> >> 983 ==60781== by 0x835430B: >>> std::_Rb_tree_iterator<std::pair<std::string const, std::pair<void const*, >>> int> > > std::_Rb_tree<std::string, std::pair<s td::string const, >>> std::pair<void const*, int> >, std::_Select1st<std::pair<std::string const, >>> std::pair<void const*, int> > >, std::less<std::string> , >>> std::allocator<std::pair<std::string const, std::pair<void const*, int> > > >>> >::_M_insert_<std::pair<std::string const, std::pair<void const*, int> >>> > >(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, >>> std::pair<std::string const, std::pair<void const*, int> >&&) >>> (stl_tree.h:1023) >> >> 984 ==60781== by 0x83548BC: _M_insert_unique_<std::pair<const >>> std::basic_string<char>, std::pair<void const*, int> > > (stl_tree.h:1482) >> >> 985 ==60781== by 0x83548BC: insert<std::pair<const >>> std::basic_string<char>, std::pair<void const*, int> >, void> >>> (stl_map.h:657) >> >> 986 ==60781== by 0x83548BC: >>> google::protobuf::SimpleDescriptorDatabase::DescriptorIndex<std::pair<void >>> const*, int> >::AddSymbol(std::string const&, s td::pair<void >>> const*, int>) (descriptor_database.cc:133) >> >> 987 ==60781== by 0x8356209: >>> google::protobuf::SimpleDescriptorDatabase::DescriptorIndex<std::pair<void >>> const*, int> >::AddFile(google::protobuf::FileD escriptorProto >>> const&, std::pair<void const*, int>) (descriptor_database.cc:69) >> >> 988 ==60781== by 0x835292A: >>> google::protobuf::EncodedDescriptorDatabase::Add(void const*, int) >>> (descriptor_database.cc:316) >> >> 989 ==60781== by 0x8322FD9: >>> google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const*, >>> int) (descriptor.cc:1394) >> >> 990 ==60781== by 0x837BAD9: >>> protobuf_google_2fprotobuf_2fduration_2eproto::AddDescriptorsImpl() ( >>> duration.pb.cc:102) >> >> 991 ==60781== by 0x82F7C6F: >>> google::protobuf::internal::FunctionClosure0::Run() (callback.h:129) >> >> 992 ==60781== by 0x82F8F90: >>> google::protobuf::GoogleOnceInitImpl(long*, google::protobuf::Closure*) >>> (once.cc:83) >> >> 993 ==60781== by 0x837BBF4: GoogleOnceInit (once.h:128) >> >> 994 ==60781== by 0x837BBF4: >>> protobuf_google_2fprotobuf_2fduration_2eproto::AddDescriptors() ( >>> duration.pb.cc:109) >> >> 995 ==60781== by 0x400F992: _dl_init (in /usr/lib64/ld-2.17.so) >> >> 996 ==60781== by 0x4001179: ??? (in /usr/lib64/ld-2.17.so) >> >> >>> > Here is the valgrind summary: > >> LEAK SUMMARY: >> >> 1812 ==60781== definitely lost: 0 bytes in 0 blocks >> >> 1813 ==60781== indirectly lost: 0 bytes in 0 blocks >> >> 1814 ==60781== possibly lost: 0 bytes in 0 blocks >> >> 1815 ==60781== still reachable: 10,402 bytes in 167 blocks >> >> 1816 ==60781== of which reachable via heuristic: >> >> 1817 ==60781== stdstring : 3,938 >>> bytes in 67 blocks >> >> 1818 ==60781== suppressed: 0 bytes in 0 blocks >> >> > > >> So i hope somebody will be able to help me :) >> >> > -Boris > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/protobuf/ad412f84-e37f-487c-bee3-5306ebdd0c8f%40googlegroups.com > <https://groups.google.com/d/msgid/protobuf/ad412f84-e37f-487c-bee3-5306ebdd0c8f%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/CADqAXr6JivgqAm9tA7EDsoo_BK%3DC2cEN8MrS9PijNcLccoq%2Byg%40mail.gmail.com.
