I have this simple qt-program like:
int main(int argc, char *argv[]) {
::QApplication app(argc, argv);
::QWidget wgt;
wgt.show();
return app.exec();
}
When I run program with Address Sinitizer, it showed me this:
==13118==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x519388 in operator new(unsigned long) (/home/andrej/Public/example/qt_ex/build/example+0x519388)
#1 0x7fc0812f9af6 in QAccessible::queryAccessibleInterface(QObject*) /build/qt510base-g_oCIy/qt510base-5.10.1/src/gui/accessible/qaccessible.cpp:720
#2 0x61300000003f (<unknown module>)
Indirect leak of 8478 byte(s) in 10 object(s) allocated from:
#0 0x4e1d60 in realloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1d60)
#1 0x7fc0746597fc (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x2d7fc)
Indirect leak of 808 byte(s) in 2 object(s) allocated from:
#0 0x4e1b10 in calloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1b10)
#1 0x7fc07465960c in _dbus_mem_pool_alloc (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x2d60c)
Indirect leak of 528 byte(s) in 2 object(s) allocated from:
#0 0x4e1b10 in calloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1b10)
#1 0x7fc07463b75d (/lib/x86_64-linux-gnu/libdbus-1.so.3+0xf75d)
Indirect leak of 480 byte(s) in 2 object(s) allocated from:
#0 0x4e1b10 in calloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1b10)
#1 0x7fc074638c37 (/lib/x86_64-linux-gnu/libdbus-1.so.3+0xcc37)
Indirect leak of 464 byte(s) in 2 object(s) allocated from:
#0 0x4e1b10 in calloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1b10)
#1 0x7fc07465577f (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x2977f)
Indirect leak of 448 byte(s) in 8 object(s) allocated from:
#0 0x4e18f8 in __interceptor_malloc (/home/andrej/Public/example/qt_ex/build/example+0x4e18f8)
#1 0x7fc0746404bd in _dbus_credentials_new (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x144bd)
Indirect leak of 280 byte(s) in 7 object(s) allocated from:
#0 0x4e18f8 in __interceptor_malloc (/home/andrej/Public/example/qt_ex/build/example+0x4e18f8)
#1 0x7fc07465f761 (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x33761)
Indirect leak of 264 byte(s) in 3 object(s) allocated from:
#0 0x4e1b10 in calloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1b10)
#1 0x7fc07464e5da (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x225da)
Indirect leak of 224 byte(s) in 2 object(s) allocated from:
#0 0x4e1b10 in calloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1b10)
#1 0x7fc07465678b in _dbus_hash_table_new (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x2a78b)
Indirect leak of 192 byte(s) in 2 object(s) allocated from:
#0 0x4e1b10 in calloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1b10)
#1 0x7fc07464b70f in _dbus_message_loader_new (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x1f70f)
Indirect leak of 192 byte(s) in 4 object(s) allocated from:
#0 0x4e18f8 in __interceptor_malloc (/home/andrej/Public/example/qt_ex/build/example+0x4e18f8)
#1 0x7fc07465f881 (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x33881)
Indirect leak of 160 byte(s) in 4 object(s) allocated from:
#0 0x4e18f8 in __interceptor_malloc (/home/andrej/Public/example/qt_ex/build/example+0x4e18f8)
#1 0x7fc07465f6fa (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x336fa)
Indirect leak of 128 byte(s) in 2 object(s) allocated from:
#0 0x4e1d60 in realloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1d60)
#1 0x7fc07464b8a1 in _dbus_message_loader_get_unix_fds (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x1f8a1)
#2 0x814dc4b6fdfc79ff (<unknown module>)
Indirect leak of 128 byte(s) in 2 object(s) allocated from:
#0 0x4e1b10 in calloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1b10)
#1 0x7fc07464cf47 (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x20f47)
Indirect leak of 96 byte(s) in 2 object(s) allocated from:
#0 0x4e1b10 in calloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1b10)
#1 0x7fc07463b728 (/lib/x86_64-linux-gnu/libdbus-1.so.3+0xf728)
Indirect leak of 96 byte(s) in 2 object(s) allocated from:
#0 0x4e1b10 in calloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1b10)
#1 0x7fc07463b717 (/lib/x86_64-linux-gnu/libdbus-1.so.3+0xf717)
Indirect leak of 80 byte(s) in 2 object(s) allocated from:
#0 0x4e1b10 in calloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1b10)
#1 0x7fc0746594b3 in _dbus_mem_pool_new (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x2d4b3)
Indirect leak of 80 byte(s) in 4 object(s) allocated from:
#0 0x4e18f8 in __interceptor_malloc (/home/andrej/Public/example/qt_ex/build/example+0x4e18f8)
#1 0x7fc07465752e in _dbus_strdup (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x2b52e)
Indirect leak of 70 byte(s) in 2 object(s) allocated from:
#0 0x4e18f8 in __interceptor_malloc (/home/andrej/Public/example/qt_ex/build/example+0x4e18f8)
#1 0x7fc074659d09 in _dbus_string_copy_data (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x2dd09)
#2 0x814dc4b6fdfc79ff (<unknown module>)
Indirect leak of 64 byte(s) in 2 object(s) allocated from:
#0 0x4e1d60 in realloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1d60)
#1 0x7fc0746565e4 (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x2a5e4)
Indirect leak of 64 byte(s) in 8 object(s) allocated from:
#0 0x4e18f8 in __interceptor_malloc (/home/andrej/Public/example/qt_ex/build/example+0x4e18f8)
#1 0x7fc074659a43 (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x2da43)
Indirect leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x4e1b10 in calloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1b10)
#1 0x7fc07464d362 (/lib/x86_64-linux-gnu/libdbus-1.so.3+0x21362)
Indirect leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x4e1b10 in calloc (/home/andrej/Public/example/qt_ex/build/example+0x4e1b10)
#1 0x7fc074639779 (/lib/x86_64-linux-gnu/libdbus-1.so.3+0xd779)
Indirect leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x519388 in operator new(unsigned long) (/home/andrej/Public/example/qt_ex/build/example+0x519388)
#1 0x7fc080dd9f75 in QtSharedPointer::ExternalRefCountData::getAndRef(QObject const*) /build/qt510base-g_oCIy/qt510base-5.10.1/src/corelib/tools/qsharedpointer.cpp:1452
Indirect leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x519388 in operator new(unsigned long) (/home/andrej/Public/example/qt_ex/build/example+0x519388)
#1 0x7fc0812ffeb1 in QAccessibleObject::QAccessibleObject(QObject*) /build/qt510base-g_oCIy/qt510base-5.10.1/src/gui/accessible/qaccessibleobject.cpp:80
#2 0x61300000003f (<unknown module>)
SUMMARY: AddressSanitizer: 13468 byte(s) leaked in 81 allocation(s).
Is this a problem? How I can cleanup output from this messages?
I read somewhere it isn't a memory leaks, but to difficult search real memory leaks, when you have this messages.
Related
I'm experimenting with coroutines in C++ using cppcoro. But Address Sanitizer seems always unhappy that I'm leaking memory. Why? I've never allocated anything using raw new/delete and have never cause a circular dependency with shared_ptr.
#include <cppcoro/task.hpp>
#include <cppcoro/sync_wait.hpp>
#include <iostream>
class A {
public:
A() { std::cerr << "A ctor\n"; }
~A() { std::cerr << "A dtor\n"; }
};
int main()
{
auto getACoro = []() -> cppcoro::task<std::shared_ptr<A>> {
co_return std::make_shared<A>();
};
auto foo = [getACoro]() -> cppcoro::task<> {
co_await getACoro();
co_return;
};
auto coro = [&foo]() -> cppcoro::task<> {
co_await foo();
};
cppcoro::sync_wait(coro());
}
Compile with: g++ -std=c++20 -focorutines main.cpp -o main -lcppcoro -g -O -fsanitize=address
Then address sanitizer complains with:
=================================================================
==274677==ERROR: LeakSanitizer: detected memory leaks
Indirect leak of 88 byte(s) in 1 object(s) allocated from:
#0 0x7ff558d7af41 in operator new(unsigned long) /build/gcc/src/gcc/libsanitizer/asan/asan_new_delete.cpp:99
#1 0x560128e69267 in operator() /home/marty/Documents/experiments/cpp/main.cpp:47
#2 0x560128e69267 in main::{lambda()#3}::operator()() const [clone .actor] /home/marty/Documents/experiments/cpp/main.cpp:50
Indirect leak of 80 byte(s) in 1 object(s) allocated from:
#0 0x7ff558d7af41 in operator new(unsigned long) /build/gcc/src/gcc/libsanitizer/asan/asan_new_delete.cpp:99
#1 0x560128e6878e in operator() /home/marty/Documents/experiments/cpp/main.cpp:43
#2 0x560128e6878e in main::{lambda()#2}::operator()() const [clone .actor] /home/marty/Documents/experiments/cpp/main.cpp:45
#3 0x560128f7b997 (/home/marty/Documents/experiments/cpp/main+0x145997)
Indirect leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7ff558d7af41 in operator new(unsigned long) /build/gcc/src/gcc/libsanitizer/asan/asan_new_delete.cpp:99
#1 0x560128e71168 in __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<A, std::allocator<A>, (__gnu_cxx::_Lock_policy)2> >::allocate(unsigned long, void const*) /usr/include/c++/10.2.0/ext/new_allocator.h:115
#2 0x560128e71168 in std::allocator<std::_Sp_counted_ptr_inplace<A, std::allocator<A>, (__gnu_cxx::_Lock_policy)2> >::allocate(unsigned long) /usr/include/c++/10.2.0/bits/allocator.h:173
#3 0x560128e71168 in std::allocator_traits<std::allocator<std::_Sp_counted_ptr_inplace<A, std::allocator<A>, (__gnu_cxx::_Lock_policy)2> > >::allocate(std::allocator<std::_Sp_counted_ptr_inplace<A, std::allocator<A>, (__gnu_cxx::_Lock_policy)2> >&, unsigned long) /usr/include/c++/10.2.0/bits/alloc_traits.h:460
#4 0x560128e71168 in std::__allocated_ptr<std::allocator<std::_Sp_counted_ptr_inplace<A, std::allocator<A>, (__gnu_cxx::_Lock_policy)2> > > std::__allocate_guarded<std::allocator<std::_Sp_counted_ptr_inplace<A, std::allocator<A>, (__gnu_cxx::_Lock_policy)2> > >(std::allocator<std::_Sp_counted_ptr_inplace<A, std::allocator<A>, (__gnu_cxx::_Lock_policy)2> >&) /usr/include/c++/10.2.0/bits/allocated_ptr.h:97
#5 0xbe0b47d5ffffffff (<unknown module>)
SUMMARY: AddressSanitizer: 192 byte(s) leaked in 3 allocation(s).
As far I can tell. The shared_ptr should have destructed right after co_await getACoro();. Why is it considered leaked? And why are the coroutine frames leaking?
Compiler: GCC 10.2
OS: Linux
How can I find out the address of direct leak in clang address sanitizer. For example, if it returns
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x40926f in operator new(unsigned long) (/home/sg/Downloads/main+0x40926f)
#1 0x428f31 in AvlTree::insert(AvlTree::Node*, int) /home/sg/Downloads/main.cpp:161:16
#2 0x428fbf in AvlTree::insert(AvlTree::Node*, int) /home/sg/Downloads/main.cpp:170:23
#3 0x428e4d in AvlTree::Insert(int) /home/sg/Downloads/main.cpp:152:16
#4 0x4293f0 in main /home/sg/Downloads/main.cpp:302:13
#5 0x7f67dd56b82f in __libc_start_main /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x40926f in operator new(unsigned long) (/home/sg/Downloads/main+0x40926f)
#1 0x428f31 in AvlTree::insert(AvlTree::Node*, int) /home/sg/Downloads/main.cpp:161:16
#2 0x428f9e in AvlTree::insert(AvlTree::Node*, int) /home/sg/Downloads/main.cpp:166:22
#3 0x428f9e in AvlTree::insert(AvlTree::Node*, int) /home/sg/Downloads/main.cpp:166:22
#4 0x428e4d in AvlTree::Insert(int) /home/sg/Downloads/main.cpp:152:16
#5 0x4293f0 in main /home/sg/Downloads/main.cpp:302:13
#6 0x7f67dd56b82f in __libc_start_main /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291
SUMMARY: LeakSanitizer: 64 byte(s) leaked in 2 allocation(s).
How could I know the address of those leaks?
I notice that the valgrind reports possible memory leak for the following minimal example:
#include <stdexcept>
int main() {
try {
throw std::logic_error("test");
}
catch (std::exception& e) {
std::string msg("test2 ");
msg.append(e.what());
throw std::logic_error(msg);
}
return 0;
}
After compiling it with g++ test.cpp -g, the valgrind detects some errors with valgrind --tool=memcheck --leak-check=full ./a.out. Is this normal?
I concern this issue because the valgrind reports some errors of my R extensions which is similar to this example.
The valgrind version is: 3.10.0.SVN. The gcc version is 4.8.2 (Ubuntu 4.8.2-19ubuntu1). The reported message is shown below:
==8640== Memcheck, a memory error detector
==8640== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8640== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==8640== Command: ./a.out
==8640==
terminate called after throwing an instance of 'std::logic_error'
what(): test2 test
==8640==
==8640== HEAP SUMMARY:
==8640== in use at exit: 354 bytes in 4 blocks
==8640== total heap usage: 6 allocs, 2 frees, 417 bytes allocated
==8640==
==8640== 29 bytes in 1 blocks are possibly lost in loss record 1 of 4
==8640== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8640== by 0x4EF13B8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x4EF2AE0: 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.19)
==8640== by 0x4EF2EF7: 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.19)
==8640== by 0x400BA7: main (test.cpp:4)
==8640==
==8640== 37 bytes in 1 blocks are possibly lost in loss record 2 of 4
==8640== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8640== by 0x4EF13B8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x4EF1F7A: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x4EF2013: std::string::reserve(unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x4EF225E: std::string::append(char const*, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x400CC6: main (test.cpp:8)
==8640==
==8640== 144 bytes in 1 blocks are possibly lost in loss record 3 of 4
==8640== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8640== by 0x4E944E2: __cxa_allocate_exception (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x400B83: main (test.cpp:4)
==8640==
==8640== 144 bytes in 1 blocks are possibly lost in loss record 4 of 4
==8640== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8640== by 0x4E944E2: __cxa_allocate_exception (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x400CD0: main (in /home/wush/Test/a.out)
==8640==
==8640== LEAK SUMMARY:
==8640== definitely lost: 0 bytes in 0 blocks
==8640== indirectly lost: 0 bytes in 0 blocks
==8640== possibly lost: 354 bytes in 4 blocks
==8640== still reachable: 0 bytes in 0 blocks
==8640== suppressed: 0 bytes in 0 blocks
==8640==
==8640== For counts of detected and suppressed errors, rerun with: -v
==8640== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 1 from 1)
Aborted (core dumped)
I am getting a memory leak with getline, and I am not sure why or how to stop it.
Here is the report from valgrind:
==26681==
==26681== HEAP SUMMARY:
==26681== in use at exit: 1,756 bytes in 73 blocks
==26681== total heap usage: 223 allocs, 150 frees, 15,523 bytes allocated
==26681==
==26681== 28 bytes in 1 blocks are possibly lost in loss record 1 of 4
==26681== at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298)
==26681== by 0x4CCC4B8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (new_allocator.h:94)
==26681== by 0x4CCD227: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (basic_string.tcc:631)
==26681== by 0x4CCD30F: std::string::reserve(unsigned long) (basic_string.tcc:512)
==26681== by 0x4CCD5D4: std::string::append(char const*, unsigned long) (basic_string.tcc:310)
==26681== by 0x4C86384: std::basic_istream<char, std::char_traits<char> >& std::getline<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> >&, char) (istream.cc:397)
==26681== by 0x4026ED: main (test.cpp:210)
==26681==
==26681== LEAK SUMMARY:
==26681== definitely lost: 0 bytes in 0 blocks
==26681== indirectly lost: 0 bytes in 0 blocks
==26681== possibly lost: 28 bytes in 1 blocks
==26681== still reachable: 1,728 bytes in 72 blocks
==26681== suppressed: 0 bytes in 0 blocks
==26681== Reachable blocks (those to which a pointer was found) are not shown.
==26681== To see them, rerun with: --leak-check=full --show-reachable=yes
==26681==
==26681== For counts of detected and suppressed errors, rerun with: -v
==26681== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)
Here is line 210 of test.cpp
bool pending = getline(inputfile, line);
Some more lines:
string line;
bool pending = getline(inputfile, line);
int round = readOption(inputfile);
int num = readOption(inputfile);
I think it has something to do with when getline fails, and because line is a string it somehow never deallocates that memory. How do I prevent this?
readOption also uses getline but I think it has no memory leaks because string line is defined locally and then goes out of scope, effectively cleaning the memory?
Edit 1:
I have "solved" the issue by making a dummy function :
bool getnewline(ifstream &inputfile) {
string line;
return getline(inputfile, line);
}
However it seems stupid to do this, I am not sure why valgrind is complaining if there is no leak. I am still after a better/clean solution to this issue.
When you exit a C++ program by calling the exit() function, the object destructors are not run. This can result in Valgrind reporting memory leaks.
I know this is almost a year old but I came upon this answer looking specifically for a getline() memory leak issue and want to give minimum instructions on how I was able to reproduce this specific issue, as I think it just comes from defining a std::string variable and not exiting cleanly from the program.
Given the following:
leaky.cpp:
#include <iostream>
int main(int argc, char ** argv) {
std::string x = "x";
exit(1);
return 0;
}
Compile string:
g++ -g -Wall -Wpedantic --std=gnu++11 leaky.cpp -o leaky
Valgrind invocation:
valgrind --tool=memcheck --leak-check=full ./leaky
Doing this will reveal that there is indeed a leak:
==4434== Memcheck, a memory error detector
==4434== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==4434== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==4434== Command: ./leaky
==4434==
==4434==
==4434== HEAP SUMMARY:
==4434== in use at exit: 16 bytes in 1 blocks
==4434== total heap usage: 1 allocs, 0 frees, 16 bytes allocated
==4434==
==4434== 16 bytes in 1 blocks are possibly lost in loss record 1 of 1
==4434== at 0x402A6DC: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==4434== by 0x40F8213: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.19)
==4434== by 0x40FA125: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.19)
==4434== by 0x40FA7AF: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.19)
==4434== by 0x804875E: main (leaky.cpp:3)
==4434==
==4434== LEAK SUMMARY:
==4434== definitely lost: 0 bytes in 0 blocks
==4434== indirectly lost: 0 bytes in 0 blocks
==4434== possibly lost: 16 bytes in 1 blocks
==4434== still reachable: 0 bytes in 0 blocks
==4434== suppressed: 0 bytes in 0 blocks
==4434==
==4434== For counts of detected and suppressed errors, rerun with: -v
==4434== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
And of course to try to include an answer to the question, exit(1) forces the program to quit without invoking any destructors, as far as I know--I've only been using C++ for a month and a half, so I'm not really an expert.
Perhaps the C++ class in question is doing something with pointers that suggests possibly leaky behavior to Valgrind.
I get diagnostics about this in a project in which I allocate some arrays, but then I adjust the pointer to the third element so that indices [-2] and [-1] are used to store some meta-information. There is no leak because I restore the pointer and free the arrays correctly.
Valgrind sees that the objects are referenced, however, that they are not referenced "nicely" via pointers to their base address, but only via interior pointers. It looks like a possible leak since no pointer exists for freeing the object.
A situation like this could happen in leaky programs: programs that, say, allocate a big object, give pieces of it (via pointers) to other modules, and then leak the big object. Interior pointers do suggest a leak.
It could be that getline is chummy with the representation of basic::string<> and does something of that sort. When you copy the object, the new object doesn't do anything funny: it just references the string data by its base address. The old object is gone, and it freed the data.
Just a hypothesis.
By the way, in that aforementioned program, I fixed things for Valgrind by retaining an extra pointer to the base address in the vector objects managing those arrays. This extra pointer is only present when the software is built for Valgrind debugging (along with other features, like use of the Valgrind client request API).
Here is my code:
std::string getword()
{
std::string temp;
std::cin >> temp;
return temp;
}
Valgrind throws an error on the line std::cin >> temp.
Here is the valgrind output for those who asked:
HEAP SUMMARY:
==18490== in use at exit: 33 bytes in 1 blocks
==18490== total heap usage: 397 allocs, 396 frees, 12,986 bytes allocated
==18490==
==18490== 33 bytes in 1 blocks are possibly lost in loss record 1 of 1
==18490== at 0x4C2AF8E: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18490== by 0x4EEE3B8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17)
==18490== by 0x4EEF127: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17)
==18490== by 0x4EEF20F: std::string::reserve(unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17)
==18490== by 0x4EA7D14: 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 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17)
==18490== by 0x401681: getword() (netsim.cc:29)
==18490== by 0x401F6E: main (netsim.cc:96)
==18490==
==18490== LEAK SUMMARY:
==18490== definitely lost: 0 bytes in 0 blocks
==18490== indirectly lost: 0 bytes in 0 blocks
==18490== possibly lost: 33 bytes in 1 blocks
==18490== still reachable: 0 bytes in 0 blocks
==18490== suppressed: 0 bytes in 0 blocks
==18490==
==18490== For counts of detected and suppressed errors, rerun with: -v
==18490== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
netsim.cc:96 is the second call to getword() in the program. That code reads
std::string network = getword();
netsim.cc:29 is the code for getword() itself. Line 29 is the line
std::cin >> temp
I still don't understand why this happened but I managed to resolve the issue.
I had the code
std::string s = getword();
immediatly above
std::string network = getword();
I made both s and network global variables and somehow the issue was resolved.
If anyone can explain why that is though I would be grateful.
I'm not a valgrind Expert, but I'm tentative to say that this is a false positive. In fact, it might even be a false positive generated by valgrind itself. Looking at the Leak Summary and seeing the core origin of the leak, I get suspicious:
// The one right below this, that's at the top of that valgrind error
==18490== at 0x4C2AF8E: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18490== by 0x4EEE3B8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17)
Now why would valgrind be reporting a memory leak from its own shared library ? Something doesn't seem right here. Either valgrind itself isn't very clean in how its allocating that memory (and valgrind has its own leak! Oh noes!) or it's throwing a really strange false positive. Unless the newest branches of GCC have produced a memory leak for std::string and the istream& operator<< recently, I can't imagine this actually leaking. std::cin and std::cout have been being used for ages, and it makes no sense that valgrind would toss an error over it, especially when your client code isn't making a single new/delete call.
So, in short, there's a few things that could be happening here:
valgrind is leaking. (Maybe? It's originating from a valgrind function)
GCC is leaking? (Hesitant to say this)
valgrind is drunk! :[
In either case, ignore it and move on. I doubt this is going to shatter your netsim in any crucial way.
I hope it clears up soon, and I'm sorry my answer can only say this much, but these are the best shots I can give.