I have class with a method:
Class Strip
with the header:
class Strip : public QMainWindow, public ILog {
And the body:
void Strip::log(const string& msg) {
ui->logFeld->append(QString::fromStdString(msg));
cout << msg << endl;
}
Which is implemented from the interface
struct ILog {
virtual void log(const string&) = 0;
};
Caller Class
In the header file of the calling class the log class is given with:
public:
LoadSetup(ILog *log): log(log) {};
In the body of the function is called with:
log->log("Error file not found or corrupted");
The problem is that cout as well as the QElement only shows: or corrupted.
Where does the rest of the string get lost or more precisely how can I correct it?
Valgrind
valgrind --leak-check=yes ./Strip > LogFile 2>&1 gives a 12k line big outputfile.
Memcheck, a memory error detector
Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
Command: ./Strip
Invalid read of size 4
at 0x6DCD0D3: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DCF464: FcConfigFilename (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DE2A15: FcConfigParseAndLoad (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8176: FcInitLoadConfig (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8265: FcInitLoadConfigAndFonts (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8484: FcInit (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x50773D9: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.1)
by 0x50049C3: QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.1)
by 0x5005283: QApplication::QApplication(int&, char**, int) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.1)
by 0x40B275: main (in /home/magu_/Strip/Strip)
Address 0xa0f6814 is 20 bytes inside a block of size 22 alloc'd
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x6DCD02C: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DCF464: FcConfigFilename (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DE2A15: FcConfigParseAndLoad (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8176: FcInitLoadConfig (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8265: FcInitLoadConfigAndFonts (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8484: FcInit (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x50773D9: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.1)
by 0x50049C3: QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.1)
by 0x5005283: QApplication::QApplication(int&, char**, int) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.1)
by 0x40B275: main (in /home/magu_/Strip/Strip)
Invalid read of size 4
at 0x6DCD0E8: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DCF464: FcConfigFilename (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DE2A15: FcConfigParseAndLoad (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DE30FD: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x8FCA6F3: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FCB950: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FC87C6: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FCA17A: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FCD75C: XML_ParseBuffer (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x6DE2B70: FcConfigParseAndLoad (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8176: FcInitLoadConfig (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8265: FcInitLoadConfigAndFonts (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
Address 0xa0fe9d0 is 16 bytes inside a block of size 18 alloc'd
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x6DCD02C: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DCF464: FcConfigFilename (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DE2A15: FcConfigParseAndLoad (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DE30FD: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x8FCA6F3: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FCB950: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FC87C6: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FCA17A: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FCD75C: XML_ParseBuffer (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x6DE2B70: FcConfigParseAndLoad (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8176: FcInitLoadConfig (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
...
LEAK SUMMARY:
definitely lost: 8,775 bytes in 44 blocks
indirectly lost: 18,528 bytes in 555 blocks
possibly lost: 462,846 bytes in 2,014 blocks
still reachable: 1,207,255 bytes in 8,462 blocks
suppressed: 0 bytes in 0 blocks
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-reachable=yes
For counts of detected and suppressed errors, rerun with: -v
ERROR SUMMARY: 930 errors from 877 contexts (suppressed: 2 from 2)
Okey most of the errors are false positives comming from Qt, I'll try to suppress those errors and try to fix it.
The problem is can't really understand the output. Any further help would be appritiated
Related
I'm running and analyzing with Valgrind this code:
int main() {
Set<int> c;
return 0;
}
So the output is:
jscherman#jscherman:~/ClionProjects/algo2-t3-bts$ g++ set.hpp tests.cpp && valgrind --leak-check=yes --show-leak-kinds=all ./a.out
==3528== Memcheck, a memory error detector
==3528== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==3528== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==3528== Command: ./a.out
==3528==
test_mleak...ok
==3528==
==3528== HEAP SUMMARY:
==3528== in use at exit: 72,704 bytes in 1 blocks
==3528== total heap usage: 2 allocs, 1 frees, 73,728 bytes allocated
==3528==
==3528== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==3528== at 0x4C2DC10: malloc (vg_replace_malloc.c:299)
==3528== by 0x4EC3EFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==3528== by 0x40104E9: call_init.part.0 (dl-init.c:72)
==3528== by 0x40105FA: call_init (dl-init.c:30)
==3528== by 0x40105FA: _dl_init (dl-init.c:120)
==3528== by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==3528==
==3528== LEAK SUMMARY:
==3528== definitely lost: 0 bytes in 0 blocks
==3528== indirectly lost: 0 bytes in 0 blocks
==3528== possibly lost: 0 bytes in 0 blocks
==3528== still reachable: 72,704 bytes in 1 blocks
==3528== suppressed: 0 bytes in 0 blocks
==3528==
==3528== For counts of detected and suppressed errors, rerun with: -v
==3528== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Apparently, i'm loosing memory at the constructor of Set, but i can't find the actual reason. This is how i implemented Set (in a BTS):
template<class T>
class Set {
public:
Set() : root_(NULL), cardinal_(0) {}
~Set() {delete root_;}
void insert(const T &);
bool belongs(const T &) const;
void remove(const T &);
const T &min() const;
const T &max() const;
unsigned int cardinal() const;
private:
struct Node {
Node(const T &v) : value(v), left(NULL), right(NULL) {}
~Node() {delete right; delete left;}
T value;
Node *left;
Node *right;
};
Node *root_;
int cardinal_;
}
Any idea how to solve this leak? Thanks!
You're not leaking anything--you're just misunderstanding what valgrind is telling you.
It thinks there may be some problem underneath _dl_init(), but this is a red herring. You can safely add it to your valgrind suppressions file (which is always a good thing to have, so you aren't bothered by false alarms from system libraries).
I'm using Valgrind on Debian 8.2. I ran valgrind -v --tool=memcheck --leak-check=yes --track-origins=yes --log-file=valgrind-$PROGRAM.log ./$PROGRAM where PROGRAM was the name of the program.
Valgrind gave me this complaint several times:
==7125== Conditional jump or move depends on uninitialised value(s)
==7125== at 0xE816EC3: ??? (in /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.340.96)
==7125== by 0x4E8DB30: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7125== by 0x4E8DBCF: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7125== by 0x4E90A92: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7125== by 0x4E887BF: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7125== by 0x403ACF: Graphics::Graphics(char const*, int, int, int, unsigned int) (Graphics.cpp:25)
==7125== by 0x401974: Game::run() (Game.cpp:62)
==7125== by 0x403EC5: main (main.cpp:13)
==7125== Uninitialised value was created by a stack allocation
==7125== at 0x4E8D830: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
And this one:
==7125== 28 bytes in 2 blocks are definitely lost in loss record 19 of 125
==7125== at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==7125== by 0x59DCA69: strdup (strdup.c:42)
==7125== by 0x66C66C6: ??? (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==7125== by 0x66C74F4: _XimSetICValueData (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==7125== by 0x66C2A28: _XimLocalCreateIC (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==7125== by 0x66A7E54: XCreateIC (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==7125== by 0x4EEFB30: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7125== by 0x4EEFF45: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7125== by 0x4EE30CB: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7125== by 0x403A88: Graphics::Graphics(char const*, int, int, int, unsigned int) (Graphics.cpp:19)
==7125== by 0x401974: Game::run() (Game.cpp:62)
==7125== by 0x403EC5: main (main.cpp:13)
The lines of main.cpp and Game.cpp Valgrind refers to lead to Graphics.cpp.
Graphics.h looks like this:
#ifndef GRAPHICS_H
#define GRAPHICS_H
struct SDL_Window;
struct SDL_Renderer;
class Graphics {
private:
const char *_windowTitle;
int _windowWidth, _windowHeight;
SDL_Window *_window;
SDL_Renderer *_renderer;
int _renderingDriverIndex;
Uint32 _rendererFlags;
public:
Graphics(const char* windowTitle, int windowWidth, int windowHeight, int renderingDriverIndex, Uint32 renderFlags);
~Graphics();
int windowWidth();
int windowHeight();
void changeWindowSize(int width, int height);
SDL_Renderer* renderer(); // since _renderer is pointer, this func must return a SDL_Renderer pointer
void setBackgroundColor();
void clear();
void update();
};
#endif /* GRAPHICS_H */
The Graphics object constructor looks like this in Graphics.cpp. Valgrind seems to be complaining about the definitions of _window and _renderer:
Graphics::Graphics(const char* windowTitle, int windowWidth, int windowHeight, int renderingDriverIndex, Uint32 renderFlags) :
_windowTitle (windowTitle),
_windowWidth (windowWidth),
_windowHeight (windowHeight),
_renderingDriverIndex (renderingDriverIndex), // get the index of the first graphics driver available(?)
_rendererFlags (renderFlags)
{
_window= SDL_CreateWindow(_windowTitle, SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, _windowWidth, _windowHeight, SDL_WINDOW_SHOWN); // LINE 19
if(_window == 0){
printError("SDL_CreateWindow");
SDL_Quit();
}
_renderer= SDL_CreateRenderer(_window, _renderingDriverIndex, _rendererFlags); // LINE 25
if(_renderer == NULL){
printError("SDL_CreateRenderer");
SDL_Quit();
}
if(SDL_SetRenderDrawBlendMode(_renderer, SDL_BLENDMODE_BLEND) == -1){
printError("SDL_SetRenderDrawBlendMode");
SDL_Quit();
}
}
Why does Valgrind complain about uninitialized variables when I define them in either Graphic's member initialization list or the class's object constructor?
I am building a dynamic library on mac in C++11 using the clang compiler and libc++ standard library. When I run valgrind on my test code which links to my dynamic library I get one block of memory that is definitely lost. Here is the valgrind report:
==45659== 36 bytes in 1 blocks are definitely lost in loss record 57 of 228
==45659== at 0x66BB: malloc (vg_replace_malloc.c:300)
==45659== by 0x31EAB0: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==45659== by 0x31F2A5: __d2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==45659== by 0x31BED6: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==45659== by 0x3438A9: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==45659== by 0x36A2DA: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==45659== by 0x34FF66: _vsnprintf (in /usr/lib/system/libsystem_c.dylib)
==45659== by 0x34FFC5: vsnprintf_l (in /usr/lib/system/libsystem_c.dylib)
==45659== by 0x34057A: snprintf_l (in /usr/lib/system/libsystem_c.dylib)
==45659== by 0x10C75A: std::__1::num_put<char, std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> > >::do_put(std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >, std::__1::ios_base&, char, double) const (in /usr/lib/libc++.1.dylib)
==45659== by 0xF3221: std::__1::basic_ostream<char, std::__1::char_traits<char> >::operator<<(double) (in /usr/lib/libc++.1.dylib)
==45659== by 0x12102: lmpsdata::header_data::write_dimension(std::__1::basic_ofstream<char, std::__1::char_traits<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (header_data.cpp:75)
==45659==
==45659== LEAK SUMMARY:
==45659== definitely lost: 36 bytes in 1 blocks
==45659== indirectly lost: 0 bytes in 0 blocks
==45659== possibly lost: 0 bytes in 0 blocks
==45659== still reachable: 18,340 bytes in 215 blocks
==45659== suppressed: 25,274 bytes in 374 blocks
That particular section of code does not deal with any memory I have dynamically allocated, only STL objects and streams are used. I have attached both the header file and the method reported by valgrind as causing the leak. Can someone please explain what is going on here? I am absolutely baffled.
header_data.h
#ifndef ____header_data__
#define ____header_data__
#include <string>
#include <fstream>
#include <cstdint>
#include <vector>
#include <map>
namespace lmpsdata {
class header_data
{//LAMMPS header information
//only the point particle header information has been implemented
//since the current atom base class is designed for point particles only
public:
header_data():xdim(2), ydim(2), zdim(2), tiltdim(3) {}
//methods
void read(const std::string &, const std::string &);
void write(std::ofstream &, const std::string &); //this write command will replace the one
std::string check_header_keyword(const std::string &, bool &);
uint64_t get(const std::string&);
std::vector<double>& get_vector(const std::string&);
void set(const std::string&, uint64_t);
void set_vector(const std::string&, std::vector<double>&);
private:
//methods
void read_dimension(const std::string&, const std::string&);
void write_dimension(std::ofstream&, const std::string&);
//members
uint64_t atomnum;
uint64_t bondnum;
uint64_t anglenum;
uint64_t dihedralnum;
uint64_t impropernum;
uint64_t atomtypenum;
uint64_t bondtypenum;
uint64_t angletypenum;
uint64_t dihedraltypenum;
uint64_t impropertypenum;
uint64_t extrabondnum;
std::vector<double> xdim;
std::vector<double> ydim;
std::vector<double> zdim;
std::vector<double> tiltdim;//for use with triclinic system
std::map<std::string, uint64_t&> int_map {
{"atoms", atomnum},
{"bonds", bondnum},
{"angles", anglenum},
{"dihedrals", dihedralnum},
{"impropers", impropernum},
{"atom types", atomtypenum},
{"bond types", bondtypenum},
{"angle types", angletypenum},
{"dihedral types", dihedraltypenum},
{"improper types", impropertypenum},
{"extra bond per atom", extrabondnum},
};
std::map<std::string, std::vector<double>&> v_map {
{"xlo xhi", xdim},
{"ylo yhi", ydim},
{"zlo zhi", zdim},
{"xy xz yz", tiltdim}
};
};
}
#endif /* defined(____header_data__) */
lmpsdata.cpp only write_dimension method and beginning of file is shown
#include "header_data.h"
#include <stdexcept>
using namespace lmpsdata;
void header_data::write_dimension(std::ofstream &file, const std::string& keyword)
{
std::vector<double>& data = v_map.at(keyword);
for (auto value: data) {
file << value << " ";
}
}
If more information is needed please let me know.
You have not mentioned the exact versions of OSX and valgrind that you're using. I've not been able to entirely reproduce this on the version that I'm using (OSX 10.10; valgrind HEAD==Valgrind-3.11.0.SVN).
This is not in the C++ standard library, but in the C library. You should be able to reproduce it (almost identically) with the simple code:
#include <stdio.h>
#include <xlocale.h>
int
main(int argc, char **argv)
{
locale_t loc = newlocale(LC_NUMERIC_MASK, "C", (locale_t)0);
double d = 22.22;
char buffer[1024];
snprintf_l(buffer, 1024, loc, "%f\n", d);
printf("%s", buffer);
freelocale(loc);
}
When run with valgrind --show-leak-kinds=all --leak-check=full ./leak I see some 'still reachable' leaks (yours should show actual leaks in this case):
==26151== 32 bytes in 1 blocks are still reachable in loss record 28 of 85
==26151== at 0x10000850B: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==26151== by 0x1002BC7DF: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002B9533: __rv_alloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002B9B3A: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002E1D52: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x10030A9AE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002EF154: _vsnprintf (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002EF1B3: vsnprintf_l (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002DF5F7: snprintf_l (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x100000ECA: main (leak.cpp:10)
==26151==
==26151== 36 bytes in 1 blocks are still reachable in loss record 30 of 85
==26151== at 0x10000850B: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==26151== by 0x1002BC7DF: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002BD055: __d2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002B986B: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002E1D52: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x10030A9AE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002EF154: _vsnprintf (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002EF1B3: vsnprintf_l (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002DF5F7: snprintf_l (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x100000ECA: main (leak.cpp:10)
==26151==
==26151== 80 bytes in 1 blocks are still reachable in loss record 47 of 85
==26151== at 0x10000850B: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==26151== by 0x1002BC736: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002BD055: __d2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002B986B: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002E1D52: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x10030A9AE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002EF154: _vsnprintf (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002EF1B3: vsnprintf_l (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x1002DF5F7: snprintf_l (in /usr/lib/system/libsystem_c.dylib)
==26151== by 0x100000ECA: main (leak.cpp:10)
I'd put in a suppression for it, as it's almost undoubtably not a real leak and is completely out of your control.
looking at the published OSX libc source, I can't see where the bug is present - 320 and later all look OK; with the underlying code appearing to allocate and free where necessary. The bug may have been introduced and fixed, though, as I didn't perform an exhaustive trawl of all the sources; the file in question is vfprintf.c, you're looking at the dtoaresult assignments & frees.
To determine your version of libc, you can do:
$ otool -l /usr/lib/system/libsystem_c.dylib | grep -A5 ID_
On my system I get the output:
cmd LC_ID_DYLIB
cmdsize 64
name /usr/lib/system/libsystem_c.dylib (offset 24)
time stamp 1 Thu Jan 1 01:00:01 1970
current version 1044.10.1
compatibility version 1.0.0
997, I think, is mavericks (10.9). I don't know if they introduced a leak in the code at some point in the mavericks timeframe and then fixed it - there doesn't appear to be a code path in the __vfprintf routine that actually leaks in any of the published source.
I correct my all memory leak in my program writing in Qt.
I found some errors which can not cope.
==3343== Conditional jump or move depends on uninitialised value(s)
==3343== at 0x80B4320: g_utf8_offset_to_pointer (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==3343== by 0x106806A0: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.23)
==3343== by 0x10680D28: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.23)
==3343== by 0x10C1ACE6: ??? (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.23)
==3343== by 0x8086CE4: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==3343== by 0x8087047: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==3343== by 0x80870EB: g_main_context_iteration (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==3343== by 0x64C2453: QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (in /home/michal/Qt/5.4/gcc_64/lib/libQt5Core.so.5.4.0)
==3343== by 0x6465DAA: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (in /home/michal/Qt/5.4/gcc_64/lib/libQt5Core.so.5.4.0)
==3343== by 0x646ACC4: QCoreApplication::exec() (in /home/michal/Qt/5.4/gcc_64/lib/libQt5Core.so.5.4.0)
==3343== by 0x406317: main (main.cpp:9)</code>
my main function
#include "mainwindow.hh"
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec(); //this is my 9th line
}
The whole day trying to fix it and I don't have any idea what's mean.
Could someone help me?
For libraries which you're not interested in and have no means to fix problems, you create valgrind suppression file and they won't be shown again
Please see manual
http://valgrind.org/docs/manual/manual-core.html
Section 2.5 Suppressing errors
I have two files:
// event_test_delete.cpp
#include <event.h>
int main() {
event_base* ev;
ev = event_init();
delete ev;
return 0;
}
And
// event_test_free.cpp
#include <event.h>
#include <cstdlib>
int main() {
event_base* ev;
ev = event_init();
free(ev);
return 0;
}
When I compile (g++ event_test_delete.cpp -levent -o event_test_delete.o) event_test_delete.cpp I get an error:
event_test_delete.cpp: In function ‘int main()’:
event_test_delete.cpp:8:9: warning: possible problem detected in invocation of delete operator:
event_test_delete.cpp:5:14: warning: ‘ev’ has incomplete type
/usr/include/event.h:211:8: warning: forward declaration of ‘struct event_base’
event_test_delete.cpp:8:9: note: neither the destructor nor the class-specific operator delete will be called, even if they are declared when the class is defined.
But when I compile g++ event_test_free.cpp -levent -o event_test_free.o event_test_free.cpp I don`t get the same error why?
And the second question is (using valgrind) why there is a memory leak?
Valgrind output for first file: (why here is an Mismatched free() / delete / delete [] ?)
azat:~/Desktop/event_test$ valgrind --show-reachable=yes --leak-check=full ./event_test_delete.o
==4135== Memcheck, a memory error detector
==4135== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==4135== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==4135== Command: ./event_test_delete.o
==4135==
==4135== Mismatched free() / delete / delete []
==4135== at 0x4023881: operator delete(void*) (vg_replace_malloc.c:387)
==4135== by 0x8048571: main (in /home/azat/Desktop/event_test/event_test_delete.o)
==4135== Address 0x4323028 is 0 bytes inside a block of size 944 alloc'd
==4135== at 0x402328F: calloc (vg_replace_malloc.c:467)
==4135== by 0x4047DA7: event_base_new (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x4047EF6: event_init (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x8048561: main (in /home/azat/Desktop/event_test/event_test_delete.o)
==4135==
==4135==
==4135== HEAP SUMMARY:
==4135== in use at exit: 672 bytes in 5 blocks
==4135== total heap usage: 6 allocs, 1 frees, 1,616 bytes allocated
==4135==
==4135== 8 bytes in 1 blocks are indirectly lost in loss record 1 of 5
==4135== at 0x4023F50: malloc (vg_replace_malloc.c:236)
==4135== by 0x4047C7D: event_base_priority_init (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x4047E8B: event_base_new (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x4047EF6: event_init (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x8048561: main (in /home/azat/Desktop/event_test/event_test_delete.o)
==4135==
==4135== 12 (4 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 5
==4135== at 0x402328F: calloc (vg_replace_malloc.c:467)
==4135== by 0x4047C2D: event_base_priority_init (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x4047E8B: event_base_new (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x4047EF6: event_init (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x8048561: main (in /home/azat/Desktop/event_test/event_test_delete.o)
==4135==
==4135== 256 bytes in 1 blocks are indirectly lost in loss record 3 of 5
==4135== at 0x402328F: calloc (vg_replace_malloc.c:467)
==4135== by 0x4056192: ??? (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x4047E46: event_base_new (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x4047EF6: event_init (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x8048561: main (in /home/azat/Desktop/event_test/event_test_delete.o)
==4135==
==4135== 384 bytes in 1 blocks are indirectly lost in loss record 4 of 5
==4135== at 0x4023F50: malloc (vg_replace_malloc.c:236)
==4135== by 0x405616C: ??? (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x4047E46: event_base_new (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x4047EF6: event_init (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x8048561: main (in /home/azat/Desktop/event_test/event_test_delete.o)
==4135==
==4135== 660 (20 direct, 640 indirect) bytes in 1 blocks are definitely lost in loss record 5 of 5
==4135== at 0x402328F: calloc (vg_replace_malloc.c:467)
==4135== by 0x4056157: ??? (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x4047E46: event_base_new (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x4047EF6: event_init (in /usr/lib/libevent-1.4.so.2.1.3)
==4135== by 0x8048561: main (in /home/azat/Desktop/event_test/event_test_delete.o)
==4135==
==4135== LEAK SUMMARY:
==4135== definitely lost: 24 bytes in 2 blocks
==4135== indirectly lost: 648 bytes in 3 blocks
==4135== possibly lost: 0 bytes in 0 blocks
==4135== still reachable: 0 bytes in 0 blocks
==4135== suppressed: 0 bytes in 0 blocks
==4135==
==4135== For counts of detected and suppressed errors, rerun with: -v
==4135== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 28 from 7)
And for second file
azat:~/Desktop/event_test$ valgrind --show-reachable=yes --leak-check=full ./event_test_free.o
==4140== Memcheck, a memory error detector
==4140== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==4140== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==4140== Command: ./event_test_free.o
==4140==
==4140==
==4140== HEAP SUMMARY:
==4140== in use at exit: 672 bytes in 5 blocks
==4140== total heap usage: 6 allocs, 1 frees, 1,616 bytes allocated
==4140==
==4140== 8 bytes in 1 blocks are indirectly lost in loss record 1 of 5
==4140== at 0x4023F50: malloc (vg_replace_malloc.c:236)
==4140== by 0x4047C7D: event_base_priority_init (in /usr/lib/libevent-1.4.so.2.1.3)
==4140== by 0x4047E8B: event_base_new (in /usr/lib/libevent-1.4.so.2.1.3)
==4140== by 0x4047EF6: event_init (in /usr/lib/libevent-1.4.so.2.1.3)
==4140== by 0x8048531: main (in /home/azat/Desktop/event_test/event_test_free.o)
==4140==
==4140== 12 (4 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 5
==4140== at 0x402328F: calloc (vg_replace_malloc.c:467)
==4140== by 0x4047C2D: event_base_priority_init (in /usr/lib/libevent-1.4.so.2.1.3)
==4140== by 0x4047E8B: event_base_new (in /usr/lib/libevent-1.4.so.2.1.3)
==4140== by 0x4047EF6: event_init (in /usr/lib/libevent-1.4.so.2.1.3)
==4140== by 0x8048531: main (in /home/azat/Desktop/event_test/event_test_free.o)
==4140==
==4140== 256 bytes in 1 blocks are indirectly lost in loss record 3 of 5
==4140== at 0x402328F: calloc (vg_replace_malloc.c:467)
==4140== by 0x4056192: ??? (in /usr/lib/libevent-1.4.so.2.1.3)
==4140== by 0x4047E46: event_base_new (in /usr/lib/libevent-1.4.so.2.1.3)
==4140== by 0x4047EF6: event_init (in /usr/lib/libevent-1.4.so.2.1.3)
==4140== by 0x8048531: main (in /home/azat/Desktop/event_test/event_test_free.o)
==4140==
==4140== 384 bytes in 1 blocks are indirectly lost in loss record 4 of 5
==4140== at 0x4023F50: malloc (vg_replace_malloc.c:236)
==4140== by 0x405616C: ??? (in /usr/lib/libevent-1.4.so.2.1.3)
==4140== by 0x4047E46: event_base_new (in /usr/lib/libevent-1.4.so.2.1.3)
==4140== by 0x4047EF6: event_init (in /usr/lib/libevent-1.4.so.2.1.3)
==4140== by 0x8048531: main (in /home/azat/Desktop/event_test/event_test_free.o)
==4140==
==4140== 660 (20 direct, 640 indirect) bytes in 1 blocks are definitely lost in loss record 5 of 5
==4140== at 0x402328F: calloc (vg_replace_malloc.c:467)
==4140== by 0x4056157: ??? (in /usr/lib/libevent-1.4.so.2.1.3)
==4140== by 0x4047E46: event_base_new (in /usr/lib/libevent-1.4.so.2.1.3)
==4140== by 0x4047EF6: event_init (in /usr/lib/libevent-1.4.so.2.1.3)
==4140== by 0x8048531: main (in /home/azat/Desktop/event_test/event_test_free.o)
==4140==
==4140== LEAK SUMMARY:
==4140== definitely lost: 24 bytes in 2 blocks
==4140== indirectly lost: 648 bytes in 3 blocks
==4140== possibly lost: 0 bytes in 0 blocks
==4140== still reachable: 0 bytes in 0 blocks
==4140== suppressed: 0 bytes in 0 blocks
==4140==
==4140== For counts of detected and suppressed errors, rerun with: -v
==4140== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 28 from 7)
When using delete the compiler needs to see the type of the object pointed to, to determine if there are any destructors it needs to call at that point.
On the other hand, valgrind seems to say that the memory is allocated using malloc and calloc. In that case, you should not use delete at all, but perhaps free.
In the second case, when using free, valgrind still complains on memory leaks. One possibility here is that the event object contains pointers to other allocations that also need to be freed.
In that case, there should be another function event_free or event_release you should call, to return the event object. Do you have one of those?
First Question: delete needs to know the type of the pointer it deletes, since it might need to call a destructor.
Seconds Question: see the comment below the question. We need to know what event_init does and how it allocates the memory to advice about existing memory leaks. However, a good advice: Trust Valgrind.
Libevent is not written in C++, and hence it does not use destructors. You should never use delete on code that hasn't been allocated using new.
If you read the libevent manual under "deallocating an event base" it states that you should use:
void event_base_free(struct event_base *base);
Also the event_new function for allocating an event base is deprecated (since it's not thread safe), you should instead use:
struct event_base *event_base_new(void);