using std::cout;...">

Why doesn't it detect a memory leak in my "test" program?

All test code is contained in main.cpp as follows:

#include <iostream> using std::cout; using std::endl; void f(int i) { int* pi = new int; *pi = i; std::cout << "*pi = " << *pi << std::endl; } int main(int argc, char *argv[]) { int i = 0; while (i < 10000) { f(i); ++i; } return 0; } 

I compile without optimization -O0 (from the Eclipse Qt project) with:

 g++ -c -pipe -O0 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -Irelease -o release/main.o main.cpp 

then the link as follows:

 g++ -Wl,-O0 -o test release/main.o -L/usr/lib -lQtGui -lQtCore -lpthread 

I run the executable via valgrind and get the following output:

 laptop:~/workspace/test$ valgrind --leak-check=yes test ==3939== Memcheck, a memory error detector ==3939== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==3939== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==3939== Command: test ==3939== ==3939== ==3939== HEAP SUMMARY: ==3939== in use at exit: 0 bytes in 0 blocks ==3939== total heap usage: 1,387 allocs, 1,387 frees, 64,394 bytes allocated ==3939== ==3939== All heap blocks were freed -- no leaks are possible ==3939== ==3939== For counts of detected and suppressed errors, rerun with: -v ==3939== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 8) 

I believe valgrind should report a memory leak, not that leaks are not possible due to the heap memory allocated when calling new int

EDIT: Changed the code above to use std :: cout rather than qDebug () with the same result

If I compile and link the same code (from the Eclipse CDT project) without Qt dependencies, valgrind detects a leak:

 g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -o"main.o" "../main.cpp" g++ -o"test2" ./main.o ==4604== HEAP SUMMARY: ==4604== in use at exit: 40,000 bytes in 10,000 blocks ==4604== total heap usage: 10,000 allocs, 0 frees, 40,000 bytes allocated ==4604== ==4604== 40,000 bytes in 10,000 blocks are definitely lost in loss record 1 of 1 ==4604== at 0x402569A: operator new(unsigned int) (vg_replace_malloc.c:255) ==4604== by 0x8048756: f(int) (main.cpp:7) ==4604== by 0x80487BB: main (main.cpp:18) ==4604== ==4604== LEAK SUMMARY: ==4604== definitely lost: 40,000 bytes in 10,000 blocks ==4604== indirectly lost: 0 bytes in 0 blocks ==4604== possibly lost: 0 bytes in 0 blocks ==4604== still reachable: 0 bytes in 0 blocks ==4604== suppressed: 0 bytes in 0 blocks ==4604== ==4604== For counts of detected and suppressed errors, rerun with: -v ==4604== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 19 from 8) 

I am using Kubuntu 10.04 32 bit and have tried both Debug and Release builds, what am I doing wrong or why doesn't valgrind report a memory leak when connecting to Qt?

+8
c ++ qt valgrind
source share
3 answers

The reason for this is because the call:

 valgrind --leak-check=yes test 

valgrind on / usr / bin / test was actually launched, which is a built-in program that checks file types and compares values, all I need:

 valgrind --leak-check=yes ./test 
+18
source share

I replaced qDebug () with std :: cout:

 ==2426== HEAP SUMMARY: ==2426== in use at exit: 40,000 bytes in 10,000 blocks ==2426== total heap usage: 10,000 allocs, 0 frees, 40,000 bytes allocated ==2426== ==2426== LEAK SUMMARY: ==2426== definitely lost: 39,996 bytes in 9,999 blocks 
0
source share

Your compiler will probably eliminate this code in optimization, try compiling with -O0 (without optimization options).

As a comment, a leak was detected with debian lenny with -O2:

 ==20547== LEAK SUMMARY: ==20547== definitely lost: 40,000 bytes in 10,000 blocks. ==20547== possibly lost: 0 bytes in 0 blocks. ==20547== still reachable: 516 bytes in 7 blocks. ==20547== suppressed: 0 bytes in 0 blocks. ==20547== Rerun with --leak-check=full to see details of leaked memory. 

Compiler:

  gcc version 4.3.2 (Debian 4.3.2-1.1) 
0
source share

Source: https://habr.com/ru/post/651431/


All Articles