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);
Related
I just move to C++ from C, and currently slicing my path through exceptions.
I'm having a hard time figuring out why am I getting a memory leak in this simple program:
#include <iostream> /* I/O */
#include <exception> /* exception */
#include <cstdlib> /* stdlib */
using namespace std;
void Bar()
{
throw exception();
}
void Foo()
{
int *ip = new int;
try
{
Bar();
}
catch(exception &e)
{
cerr << "Foo: Exception caught: " << e.what() << endl;
delete ip;
exit(1);
}
delete ip;
}
int main()
{
Foo();
return 0;
}
I feel like I'm missing something crucial here, but can't point at it. Any idea?
Valgrind's output:
==21857== Memcheck, a memory error detector
==21857== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==21857== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==21857== Command: ./a.out
==21857==
Foo: Exception caught: std::exception
==21857==
==21857== HEAP SUMMARY:
==21857== in use at exit: 136 bytes in 1 blocks
==21857== total heap usage: 3 allocs, 2 frees, 72,844 bytes allocated
==21857==
==21857== 136 bytes in 1 blocks are possibly lost in loss record 1 of 1
==21857== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21857== by 0x4ECD8FF: __cxa_allocate_exception (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25)
==21857== by 0x108CCC: Bar() (ex33.cpp:9)
==21857== by 0x108D0C: Foo() (ex33.cpp:18)
==21857== by 0x108DBD: main (ex33.cpp:31)
==21857==
==21857== LEAK SUMMARY:
==21857== definitely lost: 0 bytes in 0 blocks
==21857== indirectly lost: 0 bytes in 0 blocks
==21857== possibly lost: 136 bytes in 1 blocks
==21857== still reachable: 0 bytes in 0 blocks
==21857== suppressed: 0 bytes in 0 blocks
==21857==
==21857== For counts of detected and suppressed errors, rerun with: -v
==21857== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
You should't call exit in C++ really. Local objects destructors will not be called. And cause stack will not be unwounded, looks like destructor of exception also will not be called.
From standard:
18.1.2 When an exception is thrown, control is transferred to the nearest handler with a matching type (18.3); “nearest” means the
handler for which the compound-statement or ctor-initializer following
the try keyword was most recently entered by the thread of control and
not yet exited
18.1.3 Throwing an exception copy-initializes (11.6, 15.8) a temporary object, called the exception object. An lvalue denoting the temporary
is used to initialize the variable declared in the matching handler
(18.3). If the type of the exception object would be an incomplete
type or a pointer to an incomplete type other than cv void the program
is ill-formed.
Stack is not unwound: destructors of variables with automatic storage duration are not called. Quote from here
As it turned out, replacing exit(1) from within Foo() to return; fixed the memory leak.
So, my follow-up question, why can't I call exit() from Foo()?
int main()
{
char *p;
p = malloc(10);
delete(p);
return;
}
what will be appropriate error detected by Valgrind?
First of all this code snippet gives two compilation errors,
In function ‘int main()’:
error: invalid conversion from ‘void*’ to ‘char*’ [-fpermissive]
p = malloc(10);
^
error: return-statement with no value, in function returning ‘int’ [- fpermissive]
return;
Correct the code with these changes,
Type cast while allocating memory using malloc, as shown here.
p = (char*) malloc(10);
The return type of main function is int, so change the return value accordingly, as mentioned here.
return 0; // Use return 0, instead of just return.
Before using delete operation, do a validity check on the pointer, as shown here.
if(p)
delete(p);
With the above changes, and upon successful compilation of the above code. Use the valgrind tool to run the above sample.
As such there is no issue in the code, so valgrind did not find any issue. Below is sample valgrind output.
Valgrind output:
==30050== Memcheck, a memory error detector
==30050== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==30050== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==30050== Command: ./valgrindtest
==30050==
main Start
==30050== Mismatched free() / delete / delete []
==30050== at 0x4C2C18D: operator delete(void*) (vg_replace_malloc.c:576)
==30050== by 0x4006E0: main (valgrindtest.cpp:16)
==30050== Address 0x5a1b040 is 0 bytes inside a block of size 10 alloc'd
==30050== at 0x4C2ABE3: malloc (vg_replace_malloc.c:299)
==30050== by 0x4006C2: main (valgrindtest.cpp:11)
==30050==
main End
==30050==
==30050== HEAP SUMMARY:
==30050== in use at exit: 0 bytes in 0 blocks
==30050== total heap usage: 1 allocs, 1 frees, 10 bytes allocated
==30050==
==30050== All heap blocks were freed -- no leaks are possible
==30050==
==30050== For counts of detected and suppressed errors, rerun with: -v
==30050== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
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).
My environment is opensuse, gcc5, clion, active-mq 3.10.0.
Am my missing something? I got Segmentation fault after launch program.
class MyTask : public CompositeTask{
public:
MyTask() { }
public:
virtual bool isPending() const override {
cout<<"MyTask()::isPending\n";
return true;
}
virtual bool iterate() override {
cout<<"MyTask()::iterate\n";
return false;
}
};
class RR{
CompositeTaskRunner compositeTaskRunner;
public:
RR(){
CompositeTask* m = new MyTask();
compositeTaskRunner.addTask(m);
}
void start(){
compositeTaskRunner.start();
}
};
main(){
RR* runner = new RR();
runner->start();
}
output from valgrind
==12202== Memcheck, a memory error detector
==12202== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==12202== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==12202== Command: ./CppMicroServicesExampleDriver
==12202== Parent PID: 9602
==12202==
==12202== Invalid read of size 8
==12202== at 0x5BDCD29: createThreadInstance (Threading.cpp:365)
==12202== by 0x5BDCD29: decaf::internal::util::concurrent::Threading::createNewThread(decaf::lang::Thread*, char const*, long long) (Threading.cpp:920)
==12202== by 0x5C21BB3: decaf::lang::Thread::initializeSelf(decaf::lang::Runnable*, std::string const&, long long) (Thread.cpp:123)
==12202== by 0x5C21F7A: decaf::lang::Thread::Thread(decaf::lang::Runnable*, std::string const&) (Thread.cpp:102)
==12202== by 0x5A5AC36: activemq::threads::CompositeTaskRunner::CompositeTaskRunner() (CompositeTaskRunner.cpp:70)
==12202== by 0x40F5E1: RR::RR() (nano.hpp:32)
==12202== by 0x40BEAD: main (main.cpp:56)
==12202== Address 0x60 is not stack'd, malloc'd or (recently) free'd
==12202==
==12202==
==12202== Process terminating with default action of signal 11 (SIGSEGV)
==12202== Access not within mapped region at address 0x60
==12202== at 0x5BDCD29: createThreadInstance (Threading.cpp:365)
==12202== by 0x5BDCD29: decaf::internal::util::concurrent::Threading::createNewThread(decaf::lang::Thread*, char const*, long long) (Threading.cpp:920)
==12202== by 0x5C21BB3: decaf::lang::Thread::initializeSelf(decaf::lang::Runnable*, std::string const&, long long) (Thread.cpp:123)
==12202== by 0x5C21F7A: decaf::lang::Thread::Thread(decaf::lang::Runnable*, std::string const&) (Thread.cpp:102)
==12202== by 0x5A5AC36: activemq::threads::CompositeTaskRunner::CompositeTaskRunner() (CompositeTaskRunner.cpp:70)
==12202== by 0x40F5E1: RR::RR() (nano.hpp:32)
==12202== by 0x40BEAD: main (main.cpp:56)
==12202== If you believe this happened as a result of a stack
==12202== overflow in your program's main thread (unlikely but
==12202== possible), you can try to increase the size of the
==12202== main thread stack using the --main-stacksize= flag.
==12202== The main thread stack size used in this run was 8388608.
==12202==
==12202== HEAP SUMMARY:
==12202== in use at exit: 126,122 bytes in 577 blocks
==12202== total heap usage: 1,031 allocs, 454 frees, 152,249 bytes allocated
==12202==
==12202== LEAK SUMMARY:
==12202== definitely lost: 0 bytes in 0 blocks
==12202== indirectly lost: 0 bytes in 0 blocks
==12202== possibly lost: 0 bytes in 0 blocks
==12202== still reachable: 126,122 bytes in 577 blocks
==12202== of which reachable via heuristic:
==12202== stdstring : 15,204 bytes in 453 blocks
==12202== suppressed: 0 bytes in 0 blocks
==12202== Rerun with --leak-check=full to see details of leaked memory
==12202==
==12202== For counts of detected and suppressed errors, rerun with: -v
==12202== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Before using the library you must call its initialization method in order to prepare all the internal constructs necessary to manage the resources.
activemq::library::ActiveMQCPP::initializeLibrary();
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