C++, Valgrind reporting "possibly lost" after char* to std::string "conversion" - c++

Question

I have a class with a constructor like,
Foo::Foo(string p) {
path = p;
}
And I use it like this,
Foo foo = Foo("/tmp/foo");
Sorry for my C++ naivety. I understand that this is creating a std::string object implcitly (what's the right terminology for what's going on here?).
This causes Valgrind to complain as such,
==28188== 66 bytes in 1 blocks are possibly lost in loss record 3 of 5
==28188== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28188== by 0x4EFBF28: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24)
==28188== by 0x4EFD9B4: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24)
==28188== by 0x4EFDDDB: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24)
==28188== by 0x4EC2B05: std::logic_error::logic_error(char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24)
==28188== by 0x4EC5AA8: std::__throw_logic_error(char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24)
==28188== by 0x4EFDA38: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24)
==28188== by 0x4EFDDDB: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24)
==28188== by 0x4022F3: main (main.cpp:13)
==28188==
==28188== 144 bytes in 1 blocks are possibly lost in loss record 4 of 5
==28188== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28188== by 0x4E9FF9F: __cxa_allocate_exception (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24)
==28188== by 0x4EC5A92: std::__throw_logic_error(char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24)
==28188== by 0x4EFDA38: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24)
==28188== by 0x4EFDDDB: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24)
==28188== by 0x4022F3: main (main.cpp:13)
It looks like ultimately the "conversion" (sorry again) new'ing a std::string.
If I change my code to this,
string d = string("/tmp");
Foo Foo = Foo(d);
Valgrind does not report the leak.
This is really a leak, right? Seems like it.
What's the proper idiom to do what I'm doing here? I want the call semantics to be able to pass a char* but internally I want the class member to be a std::string.

Answer 1

The Valgrind error that you're getting seems to suggest that your program terminated abnormally due to an exception. You can see this through the call stack: it looks like an internal std::__throw_exception function is getting called and that there's an object of type std::logic_error getting constructed. From context, it seems like what's happening here is that you passed an invalid argument into the std::string constructor, which then caused the std::logic_error to get thrown, causing a different std::string to get constructed and then thrown. Since the program terminated due to an exception, the destructors for the std::strings constructed this way never got called, hence the leak.
I'd run this program in gdb rather than valgrind to see if you can debug the source of the error. From what you've posted above I don't think we have enough context to provide any specific insights.

Answer 2

Problem here is when you passed string literal which is actually of type const char * (c string) to const string , compiler creates temporary object by invoking overaloded ctor string(const char * ). This temporary object is then passed by value to Foo().
Temporary object of type string has internal allocation created something on heap and it should be freed when temporary object goes out of scope.
This is not definite memory leak but valgrind thinks (due to temp object doesnot have definite starting pointer pointing to it) in that way.
That's the reason it is reported as possbily lost (and not definitely lost).

Answer 3

The idiom I like to use is Foo::Foo(const std::string &str)
Passes strings by reference, but also allows for string literals.
The one thing to look out for is a NULL char pointer. That is quite possibly what you are seeing.