Thanks Adam! Again you are of great help.

That's what I expected. I want them to dissappear  because i am trying 
catch possible real leaks and protobuf messages just flooding the valgrind 
log.

 

Thanks.


P.S. I already implemented your suggestion and it worked 


#include <google/protobuf/stubs/common.h>

google::protobuf::ShutdownProtobufLibrary();


linking with protobuf

On Monday, October 21, 2019 at 12:26:38 PM UTC-4, Adam Cozzette wrote:
>
> 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] 
> <javascript:>> 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] <javascript:>.
>> 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/94385e25-dac5-4793-b274-d34e672ba69f%40googlegroups.com.

Reply via email to