I have a very simple C++ program.
#include <iostream>
int main()
{
std::cout << "HI" << std::endl;
return 0;
}
I compile this on a Mac with the command c++ --std=c++11 leak.cpp.
When I debug this with valgrind --leak-check=full ./a.out, I get the following output:
==2187== HEAP SUMMARY:
==2187== in use at exit: 38,906 bytes in 429 blocks
==2187== total heap usage: 508 allocs, 79 frees, 45,074 bytes allocated
==2187==
==2187== LEAK SUMMARY:
==2187== definitely lost: 0 bytes in 0 blocks
==2187== indirectly lost: 0 bytes in 0 blocks
==2187== possibly lost: 0 bytes in 0 blocks
==2187== still reachable: 4,096 bytes in 1 blocks
==2187== suppressed: 34,810 bytes in 428 blocks
==2187== Reachable blocks (those to which a pointer was found) are not shown.
==2187== To see them, rerun with: --leak-check=full --show-leak-kinds=all
Turns out there are 4096 bytes that are "still reachable". If I remove the cout statement then there are no more "still reachable" bytes.
Why is it the case that outputting to std::cout causes a memory leak?
It could be a false positive in the leak report. Valgrind can only be so clever; your standard library implementation is taking certain liberties that Valgrind doesn't have a special case for.
I'd be more worried about figuring out why this tiny program is performing 508 allocations, to a total of 45,074 bytes.
Related
Following is a section of the output of the log-file from Valgrind using the following command:
valgrind --leak-check=full --show-leak-kinds=all --verbose
--log-file=valgrind_output.txt ./TestMatlab
==12340==
==12340== HEAP SUMMARY:
==12340== in use at exit: 8,132 bytes in 99 blocks
==12340== total heap usage: 3,810 allocs, 3,711 frees, 436,330 bytes allocated
==12340==
==12340== Searching for pointers to 99 not-freed blocks
==12340== Checked 3,940,672 bytes
...
...
...
==12340== LEAK SUMMARY:
==12340== definitely lost: 0 bytes in 0 blocks
==12340== indirectly lost: 0 bytes in 0 blocks
==12340== possibly lost: 0 bytes in 0 blocks
==12340== still reachable: 8,132 bytes in 99 blocks
==12340== suppressed: 0 bytes in 0 blocks
==12340==
==12340== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==12340== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
The C++ program is a very simple code that just instantiates an object of the engine API for C++ interface and subsequently closes the engine interface. The code is shown below:
#include "engine.h"
#include <iostream>
#include <stdlib.h>
int main() {
Engine *ep;
if (!(ep = engOpen(""))) {
std::cout <<"\nCan't start MATLAB engine" << std::endl;
return EXIT_FAILURE;
}
std::cout << "Done!" << std::endl;
engClose(ep);
return 0;
}
Can this issue be fixed? If so how can I do it?
I'm trying out boost threads and I noticed from valgrind that it is leaking 320 bytes just from looping through an empty block of code. I found some posts on google from 2010 that suggests that they are likely a false positive from threads not closing before valgind runs through, but this is slightly different. In those examples you had a few blocks that were still reachable (therefor, freeable if threads were still running) where my run shows 8 as still reachable and 20 blocks as definitely lost. Is this something I should worry about, or am I somehow missing something? Thanks
The code
#include <boost/thread.hpp>
#include <iostream>
#define THREADS 20
void threadfunc(int workerid) {}
int main(int argc, char **argv){
boost::thread *threads[THREADS];
int i;
for (i = 0; i < THREADS; i++) {
threads[i] = new boost::thread(threadfunc, i);
}
for (i = 0; i < THREADS; i++) {
threads[i]->join();
}
}
Compile command
c++ -o example example.cpp -I /usr/include/boost -lboost_system -lboost_thread
Valgind command
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes --num-callers=40 --log-file=valgrind.log ./example
Valgine results
==31674== HEAP SUMMARY:
==31674== in use at exit: 328 bytes in 21 blocks
==31674== total heap usage: 103 allocs, 82 frees, 14,968 bytes allocated
==31674==
==31674== Searching for pointers to 21 not-freed blocks
==31674== Checked 215,920 bytes
==31674==
==31674== 8 bytes in 1 blocks are still reachable in loss record 1 of 2
==31674== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31674== by 0x4E454A9: boost::detail::get_once_per_thread_epoch() (in /usr/lib/libboost_thread.so.1.46.1)
==31674== by 0x4E3E4FF: ??? (in /usr/lib/libboost_thread.so.1.46.1)
==31674== by 0x4E3E7C8: boost::detail::get_current_thread_data() (in /usr/lib/libboost_thread.so.1.46.1)
==31674== by 0x4E3FF3A: boost::thread::join() (in /usr/lib/libboost_thread.so.1.46.1)
==31674== by 0x402C79: main (in /home/Jason/php/base/example)
==31674==
==31674== 320 bytes in 20 blocks are definitely lost in loss record 2 of 2
==31674== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31674== by 0x402C2A: main (in /home/Jason/php/base/example)
==31674==
==31674== LEAK SUMMARY:
==31674== definitely lost: 320 bytes in 20 blocks
==31674== indirectly lost: 0 bytes in 0 blocks
==31674== possibly lost: 0 bytes in 0 blocks
==31674== still reachable: 8 bytes in 1 blocks
==31674== suppressed: 0 bytes in 0 blocks
==31674==
==31674== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
--31674--
--31674-- used_suppression: 2 dl-hack3-cond-1
==31674==
==31674== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
It's your errors, not boost::threads.
Your memory are not freed.
for (i = 0; i < THREADS; i++) {
threads[i] = new boost::thread(threadfunc, i);
}
Before exit from main function you must free memory (delete threads).
Something like
for (i = 0; i < THREADS; i++) {
delete threads[i];
}
or delete next after join.
==11136== Invalid read of size 8
==11136== at 0x5AFC696: memrchr (memrchr.S:289)
==11136== by 0x5B57FAF: dirname (dirname.c:45)
==11136== by 0x405F43: push::lg_cmd_dirname(push::Env&) (LGExtension.cpp:379)
==11136== by 0x42533C: push::Instruction::operator()(push::Env&) const (in /home/bots/svn/eco/branches/skynet_BigPUSH/src/push3.0/extension/push_bloodline)
==11136== by 0x488ECD: push::Env::go(int) (Env.cpp:72)
==11136== by 0x4A84D5: main (bloodline.cpp:99)
==11136== Address 0x640daf8 is 8 bytes inside a block of size 10 alloc'd
==11136== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11136== by 0x5AEF801: strdup (strdup.c:43)
==11136== by 0x405EF2: push::lg_cmd_dirname(push::Env&) (LGExtension.cpp:369)
==11136== by 0x42533C: push::Instruction::operator()(push::Env&) const (in /home/bots/svn/eco/branches/skynet_BigPUSH/src/push3.0/extension/push_bloodline)
==11136== by 0x488ECD: push::Env::go(int) (Env.cpp:72)
==11136== by 0x4A84D5: main (bloodline.cpp:99)
==11136==
Is this a legitimate error? It looks like the read takes place inside a valid block. In my program, the call looks like this:
char *path = strdup(full_path.c_str());
cerr << "Path is : " << path << endl;
result = dirname(path);
if(result < 0){
cerr << "Dirname failed for some reason. Check log." << endl;
}
and the output to cerr at the time of the error is:
Path is : /tmp/tmp/
which is a valid path. Dirname shouldn't have any trouble with this, and it's operating on a heap allocated duplicate.
EDIT:
Here is a minimal example that will produce this error:
#include <string.h>
#include <stdio.h>
#include <iostream>
#include <libgen.h>
int main(){
char *path = strdup("/tmp/tmp/");
char* result = dirname(path);
std::cerr << result << std::endl;
}
compile with g++.
run with valgrind, and you get:
==32466== Memcheck, a memory error detector
==32466== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==32466== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==32466== Command: ./a.out
==32466==
==32466== Invalid read of size 8
==32466== at 0x51C7696: memrchr (memrchr.S:289)
==32466== by 0x5222FAF: dirname (dirname.c:45)
==32466== by 0x400865: main (in /home/j3doucet/a.out)
==32466== Address 0x59ff048 is 8 bytes inside a block of size 10 alloc'd
==32466== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32466== by 0x51BA801: strdup (strdup.c:43)
==32466== by 0x400855: main (in /home/j3doucet/a.out)
==32466==
/tmp
==32466==
==32466== HEAP SUMMARY:
==32466== in use at exit: 10 bytes in 1 blocks
==32466== total heap usage: 1 allocs, 0 frees, 10 bytes allocated
==32466==
==32466== LEAK SUMMARY:
==32466== definitely lost: 10 bytes in 1 blocks
==32466== indirectly lost: 0 bytes in 0 blocks
==32466== possibly lost: 0 bytes in 0 blocks
==32466== still reachable: 0 bytes in 0 blocks
==32466== suppressed: 0 bytes in 0 blocks
==32466== Rerun with --leak-check=full to see details of leaked memory
==32466==
==32466== For counts of detected and suppressed errors, rerun with: -v
==32466== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Valgrind indicates that a read of size 8 is done from the byte nr 8 in
a block of 10 bytes.
This read is done by memrchr.
Such functions are often optimised based on the assumption that you can read
more bytes than the allocated block.
To avoid reporting such problems, Valgrind has to replace such optimised
functions by its own redefining function.
memrchr has only been redefined in Valgrind from version 3.8 onwards.
=> you should retry with the latest version of Valgrind (3.8.1).
Error might then not be reported anymore (assuming it is effectively a false positive
due to non redefinition of memrchr).
I am wondering if the size of float and double objects are equal from std::list point of view?
I've allocated 5-million Real(alias float or double) objects in a std::list and used Valgrind to monitor memory usage.
in both cases the used memory is equal although the size of a 'double' (8 bytes) is double the size if a 'float' object (4 bytes)!
Btw, when I allocate memory for the same amount of objects using 'new' operator, the memory usage of the double array is double the usage of the float array, which seems about right. I was expecting the same using std::list too.
I am using gcc 4.6.2, on Fedora 16.x86_64.
Any idea to help me figure the mystery is appreciated.
here is the code I wrote for test
#include <iostream>
#include <list>
typedef double Real;
int main(int argc, char** argv)
{
std::list<Real> pts;
int k;
int npts = 5000000; // 5 mil
std::cout << "sizeof(Real): " << sizeof(Real) << std::endl;
for(k=0; k < npts;++k)
pts.push_back(1.0);
return 0;
}
if I define Real <- double the Valgrind output is
==15335== Memcheck, a memory error detector
==15335== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==15335== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==15335== Command: /home/soheil/Workspace/tbin/test_memory_usage
==15335==
sizeof(Real): 8
==15335==
==15335== HEAP SUMMARY:
==15335== in use at exit: 616 bytes in 6 blocks
==15335== total heap usage: 5,000,053 allocs, 5,000,047 frees, 120,015,245 bytes allocated
==15335==
==15335== LEAK SUMMARY:
==15335== definitely lost: 0 bytes in 0 blocks
==15335== indirectly lost: 0 bytes in 0 blocks
==15335== possibly lost: 0 bytes in 0 blocks
==15335== still reachable: 616 bytes in 6 blocks
==15335== suppressed: 0 bytes in 0 blocks
==15335== Rerun with --leak-check=full to see details of leaked memory
==15335==
==15335== For counts of detected and suppressed errors, rerun with: -v
==15335== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
if I define Real <- float the Valgrind output is
==15252== Memcheck, a memory error detector
==15252== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==15252== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==15252== Command: /home/soheil/Workspace/tbin/test_memory_usage
==15252==
sizeof(Real): 4
==15252==
==15252== HEAP SUMMARY:
==15252== in use at exit: 616 bytes in 6 blocks
==15252== total heap usage: 5,000,053 allocs, 5,000,047 frees, 120,015,245 bytes allocated
==15252==
==15252== LEAK SUMMARY:
==15252== definitely lost: 0 bytes in 0 blocks
==15252== indirectly lost: 0 bytes in 0 blocks
==15252== possibly lost: 0 bytes in 0 blocks
==15252== still reachable: 616 bytes in 6 blocks
==15252== suppressed: 0 bytes in 0 blocks
==15252== Rerun with --leak-check=full to see details of leaked memory
==15252==
==15252== For counts of detected and suppressed errors, rerun with: -v
==15252== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
Each element in a std::list<T> is a linked-list node, so it's a struct containing two pointers, as well as the payload data of type T. For instance, for GCC 4.1.2, it's as follows:
struct _List_node_base
{
_List_node_base* _M_next;
_List_node_base* _M_prev;
// *** Non-virtual member functions ***
};
template<typename _Tp>
struct _List_node : public _List_node_base
{
_Tp _M_data;
};
The size allocated will be the size of that struct; if T is small enough then you may be seeing the figures dominated by struct padding.
So with the GCC definition, that's two 64-bit pointers (so 16 bytes), plus 4 or 8 bytes T, padded up to 8 bytes, so 24 bytes in total, which matches what you're measuring.
To test the theory, try changing Real to be float[2] or double[2].
I'm atempting to learn xerces-c and was following this tutorial online.
http://www.yolinux.com/TUTORIALS/XML-Xerces-C.html
I was able to get the tutorial to compile and run through a memory checker (valgrind) with no problems however when I made alterations to the program slightly, the memory checker returned some potential leak bytes. I only added a few extra lines to main to allow the program to read two files instead of one.
int main()
{
string configFile="sample.xml"; // stat file. Get ambigious segfault otherwise.
GetConfig appConfig;
appConfig.readConfigFile(configFile);
cout << "Application option A=" << appConfig.getOptionA() << endl;
cout << "Application option B=" << appConfig.getOptionB() << endl;
// Added code
configFile = "sample1.xml";
appConfig.readConfigFile(configFile);
cout << "Application option A=" << appConfig.getOptionA() << endl;
cout << "Application option B=" << appConfig.getOptionB() << endl;
return 0;
}
I was wondering why is it when I added the extra lines of code to read in another xml file, it would result in the following output?
==776== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==776== Command: ./a.out
==776==
Application option A=10
Application option B=24
Application option A=30
Application option B=40
==776==
==776== HEAP SUMMARY:
==776== in use at exit: 6 bytes in 2 blocks
==776== total heap usage: 4,031 allocs, 4,029 frees, 1,092,045 bytes allocated
==776==
==776== 3 bytes in 1 blocks are definitely lost in loss record 1 of 2
==776== at 0x4C28B8C: operator new(unsigned long) (vg_replace_malloc.c:261)
==776== by 0x5225E9B: xercesc_3_1::MemoryManagerImpl::allocate(unsigned long) (MemoryManagerImpl.cpp:40)
==776== by 0x53006C8: xercesc_3_1::IconvGNULCPTranscoder::transcode(unsigned short const*, xercesc_3_1::MemoryManager*) (IconvGNUTransService.cpp:751)
==776== by 0x4038E7: GetConfig::readConfigFile(std::string&) (in /home/bonniehan/workspace/test/a.out)
==776== by 0x403B13: main (in /home/bonniehan/workspace/test/a.out)
==776==
==776== 3 bytes in 1 blocks are definitely lost in loss record 2 of 2
==776== at 0x4C28B8C: operator new(unsigned long) (vg_replace_malloc.c:261)
==776== by 0x5225E9B: xercesc_3_1::MemoryManagerImpl::allocate(unsigned long) (MemoryManagerImpl.cpp:40)
==776== by 0x53006C8: xercesc_3_1::IconvGNULCPTranscoder::transcode(unsigned short const*, xercesc_3_1::MemoryManager*) (IconvGNUTransService.cpp:751)
==776== by 0x40393F: GetConfig::readConfigFile(std::string&) (in /home/bonniehan/workspace/test/a.out)
==776== by 0x403B13: main (in /home/bonniehan/workspace/test/a.out)
==776==
==776== LEAK SUMMARY:
==776== definitely lost: 6 bytes in 2 blocks
==776== indirectly lost: 0 bytes in 0 blocks
==776== possibly lost: 0 bytes in 0 blocks
==776== still reachable: 0 bytes in 0 blocks
==776== suppressed: 0 bytes in 0 blocks
==776==
==776== For counts of detected and suppressed errors, rerun with: -v
==776== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2)
Looks like the example code has some shortcomings for your use case. It contains this code:
m_OptionA = XMLString::transcode(xmlch_OptionA);
From the documentation we can see that transcode requires its caller to deallocate the returned (C-style) string with XMLString::release(). We can see that this is done in the GetConfig destructor:
if(m_OptionA) XMLString::release( &m_OptionA );
But this code does not exist in readConfig(). You should add it there. You may also want to initialize those C-style string members to NULL in the constructor, or you will face another memory problem (potentially a crash bug) if you call readConfig() zero times instead of one or two.