0
votes

In my project i am using jsoncpp, boost and many libraries, when i ran the valgrind for my program in many palces including jsoncpp, boost libraries it shows possible memory leak in string creation

I have pasted the valgrind error snippets

==5506== 427,198 bytes in 489 blocks are possibly lost in loss record 8,343 of 8,359

==5506== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)

==5506== by 0x9360A88: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)

==5506== by 0x55EB0BD: char* std::string::_S_construct(char const*, char const*, std::allocator const&, std::forward_iterator_tag) (basic_string.tcc:140)

==5506== by 0x936261C: std::basic_string, std::allocator >::basic_string(char const*, unsigned long, std::allocator const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)

==5506== by 0x63FEB99: Json::Value::asString() const (json_value.cpp:611)

My question is are these errors are valid or they are false positive ?

Thanks in advance

2
check (json_value.cpp:611), maybe std::string itself is 'possibly lost' (allocated by new, part of union etc.)Hcorg
@Hcorg I checked the line((json_value.cpp:611) it is 'return std::string(this_str, this_len);' The 'this_str' is a char const* str and 'this_len' is unsigned i don't find them as leak sourceCharzhard
Where is your testcase?Lightness Races in Orbit

2 Answers

2
votes

To be completely sure, you can do a looped test and check for memory hogging.

We had similar messages and they turned out to be false positives, so we added them to the suppression list.

1
votes

Valgrind has some heuristics that reduces the number of 'false positive' possibly lost.

A.o., it has an heuristic to better detect std::string.

Use the following options to activate some heuristics: --leak-check-heuristics=heur1,heur2,... which heuristics to use for improving leak search false positive [none] where heur is one of: stdstring length64 newarray multipleinheritance all none

Note that in the upcoming 3.11 release, the default for this option has been changed from 'none' to 'all'.