Valgrind is Telling me there are bytes allocated on my heap? [duplicate] - c++

I have developed a pure-C implementation of FIFO lists (queues) in files fifo.h and fifo.c, and have written a test programme testfifo.c which I compile to ./bin/testfifo. The node structure is defined in list.h.
I run my programme through Valgrind on OS X 10.6 like this
valgrind --tool=memcheck --leak-check=full --show-reachable=yes ./bin/testfifo
and get the following output
==54688== Memcheck, a memory error detector
==54688== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==54688== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==54688== Command: bin/testfifo
==54688==
--54688-- bin/testfifo:
--54688-- dSYM directory is missing; consider using --dsymutil=yes
==54688==
==54688== HEAP SUMMARY:
==54688== in use at exit: 88 bytes in 1 blocks
==54688== total heap usage: 11 allocs, 10 frees, 248 bytes allocated
==54688==
==54688== LEAK SUMMARY:
==54688== definitely lost: 0 bytes in 0 blocks
==54688== indirectly lost: 0 bytes in 0 blocks
==54688== possibly lost: 0 bytes in 0 blocks
==54688== still reachable: 0 bytes in 0 blocks
==54688== suppressed: 88 bytes in 1 blocks
==54688==
==54688== For counts of detected and suppressed errors, rerun with: -v
==54688== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
According to the leak summary, there are no leaks, but I am still wondering what the "suppressed" leaks are. Besides, the number of alloc's and free's do not match, and hence I am unsure if there are leaks or not.
----EDIT----
Running
valgrind --tool=memcheck --leak-check=full --show-reachable=yes -v ./bin/testfifo
on OS X 10.6 produces a quite long and confusing output, but I have run
valgrind --tool=memcheck --leak-check=full --show-reachable=yes ./bin/testfifo
on a Linux machine an got this output:
==32688== Memcheck, a memory error detector
==32688== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==32688== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==32688== Command: bin/testfifo
==32688==
==32688==
==32688== HEAP SUMMARY:
==32688== in use at exit: 0 bytes in 0 blocks
==32688== total heap usage: 10 allocs, 10 frees, 160 bytes allocated
==32688==
==32688== All heap blocks were freed -- no leaks are possible
==32688==
==32688== For counts of detected and suppressed errors, rerun with: -v
==32688== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
alloc's and free's now match, so the extra alloc on OS X seems to be due to some system library, as has been suggested.
I have run the very same command with the -v option, in order to reveal the 4 suppressed errors, but I have not got any easily understandable new information.

Those are leaks outside of your code, in (probably shared) libraries or known false positives. Running valgrind with -v should inform you about the suppressions used.

Related

Using Valgrind with Qt from command line to debug memory error

I'm having a memory error in my Qt-based application, I'm trying to use the Valgrind tool to detect the error but unfortunately when using Valgrind with my executable it runs and finishes without opening the GUI.
My command used is:
valgrind --track-origin=yes executable_path
The output is:
==4982== Memcheck, a memory error detector
==4982== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4982== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==4982== Command: executable_path
==4982==
==4982== HEAP SUMMARY:
==4982== in use at exit: 2,661,594 bytes in 33,665 blocks
==4982== total heap usage: 36,967 allocs, 3,302 frees, 3,228,496 bytes allocated
==4982==
==4982== LEAK SUMMARY:
==4982== definitely lost: 0 bytes in 0 blocks
==4982== indirectly lost: 0 bytes in 0 blocks
==4982== possibly lost: 1,962,915 bytes in 27,027 blocks
==4982== still reachable: 698,679 bytes in 6,638 blocks
==4982== suppressed: 0 bytes in 0 blocks
==4982== Rerun with --leak-check=full to see details of leaked memory
==4982==
==4982== For counts of detected and suppressed errors, rerun with: -v
==4982== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 10 from 6)
My expectation is that this command will open the GUI and I'll do the steps for reproducing the issue then when I close the tool the report is written in the terminal, so what is wrong with the command that causes Valgrind to finish before even opening the tool.

C++ program does nothing but Valgrind shows memory alloc

I was toying around with Valgrind, when I noticed something weird:
my C++ program does nothing, yet there is 1 memory alloc and 1 free.
My simple program:
int main() {
return 0;
}
when compiled with g++ and checked with Valgrind
> g++ main.cpp
> valgrind --leak-check=full --track-origins=yes ./a.out
==40790== Memcheck, a memory error detector
==40790== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==40790== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright info
==40790== Command: ./a.out
==40790==
==40790==
==40790== HEAP SUMMARY:
==40790== in use at exit: 0 bytes in 0 blocks
==40790== total heap usage: 1 allocs, 1 frees, 72,704 bytes allocated
==40790==
==40790== All heap blocks were freed -- no leaks are possible
==40790==
==40790== For lists of detected and suppressed errors, rerun with: -s
==40790== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
My question: My program does nothing. Where does the alloc and free come from?
Interestingly enough, the same program compiled with gcc, shows zero allocs and frees:
> gcc main.c
> valgrind --leak-check=full --track-origins=yes ./a.out
==40740== Memcheck, a memory error detector
==40740== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==40740== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright info
==40740== Command: ./a.out
==40740==
==40740==
==40740== HEAP SUMMARY:
==40740== in use at exit: 0 bytes in 0 blocks
==40740== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==40740==
==40740== All heap blocks were freed -- no leaks are possible
==40740==
==40740== For lists of detected and suppressed errors, rerun with: -s
==40740== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Follow up question: Why do the two memory allocations differ, for the same piece of code?
compiler: gcc (GCC) 10.1.0
valgrind: valgrind-3.16.0.GIT
The main function is the entry point of your code. It doesn't have to be (and seldom is) the entry point to the process for the operating system that is loading your program.
There's usually plenty of code running first to set up things needed for the standard library (like setting up the standard I/O streams, and fetching the actual arguments from the operating system) before your main function is called.
And it's important to note that the main function is called like any other function. Once it returns it will return to the initialization code which will now clean up after itself (like freeing memory it might have allocated, and closing streams, etc.).

Valgrind reports memory leak related with CRYPTO_zalloc in a c++ app but no additional info

I've created a c++ app in an arm embedded board .The board uses armbian linux debian flavour. This app in several places execute https request with the help of poco NetSSl library.
When I run the valgrind with the following arguments:
valgrind --leak-check=full --leak-resolution=high --show-reachable=yes --num-callers=20 --track-origins=yes --show-below-main=yes --log-file=valrgind.log ./c++_app
I get the following error message :
==2414== Memcheck, a memory error detector
==2414== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2414== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==2414== Command: ./c++_app
==2414== Parent PID: 1556
==2414==
disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E
==2414== valgrind: Unrecognised instruction at address 0x52a17e7.
==2414== at 0x52A17E6: ??? (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414== Your program just tried to execute an instruction that Valgrind
==2414== did not recognise. There are two possible reasons for this.
==2414== 1. Your program has a bug and erroneously jumped to a non-code
==2414== location. If you are running Memcheck and you just saw a
==2414== warning about a bad jump, it's probably your program's fault.
==2414== 2. The instruction is legitimate but Valgrind doesn't handle it,
==2414== i.e. it's Valgrind's fault. If you think this is the case or
==2414== you are not sure, please let us know and we'll try to fix it.
==2414== Either way, Valgrind will now raise a SIGILL signal which will
==2414== probably kill your program.
==2414== Thread 5:
==2414== Syscall param write(buf) points to uninitialised byte(s)
==2414== at 0x5153D12: write (syscall-template.S:84)
==2414== by 0x52B8A29: ??? (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414== Address 0x59d78f6 is 382 bytes inside a block of size 16,472 alloc'd
==2414== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2414== by 0x5217FCB: ??? (in /usr/lib/arm-linux-gnueabihf/libssl.so.1.1)
==2414== Uninitialised value was created by a heap allocation
==2414== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2414== by 0x52CE4FB: BUF_MEM_grow_clean (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414==
==2414==
==2414== HEAP SUMMARY:
==2414== in use at exit: 400 bytes in 2 blocks
==2414== total heap usage: 57,828 allocs, 57,826 frees, 4,335,151 bytes allocated
==2414==
==2414== Thread 1:
==2414== 400 bytes in 2 blocks are definitely lost in loss record 1 of 1
==2414== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2414== by 0x5332337: CRYPTO_zalloc (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414==
==2414== LEAK SUMMARY:
==2414== definitely lost: 400 bytes in 2 blocks
==2414== indirectly lost: 0 bytes in 0 blocks
==2414== possibly lost: 0 bytes in 0 blocks
==2414== still reachable: 0 bytes in 0 blocks
==2414== suppressed: 0 bytes in 0 blocks
==2414==
==2414== For counts of detected and suppressed errors, rerun with: -v
==2414== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 0 from 0)
Since I've dealt with similar problems when using gdb I gave export OPENSSL_armcap=0 and then I got the following:
==2435== Memcheck, a memory error detector
==2435== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2435== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==2435== Command: ./c++_app
==2435== Parent PID: 1556
==2435==
==2435==
==2435== HEAP SUMMARY:
==2435== in use at exit: 400 bytes in 2 blocks
==2435== total heap usage: 158,181 allocs, 158,179 frees, 11,872,290 bytes allocated
==2435==
==2435== 400 bytes in 2 blocks are definitely lost in loss record 1 of 1
==2435== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2435== by 0x5332337: CRYPTO_zalloc (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2435==
==2435== LEAK SUMMARY:
==2435== definitely lost: 400 bytes in 2 blocks
==2435== indirectly lost: 0 bytes in 0 blocks
==2435== possibly lost: 0 bytes in 0 blocks
==2435== still reachable: 0 bytes in 0 blocks
==2435== suppressed: 0 bytes in 0 blocks
==2435==
==2435== For counts of detected and suppressed errors, rerun with: -v
==2435== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
However no additional info was retrieved even though I've compiled the code with -ggdb3.
The info that I get from openssl version -a is:
OpenSSL 1.1.0j 20 Nov 2018
built on: reproducible build, date unspecified
platform: debian-armhf
options: bn(64,32) rc4(char) des(long) blowfish(ptr)
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/arm-linux-gnueabihf/engines-1.1\""
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/arm-linux-gnueabihf/engines-1.1"
I've found several issues regarding memory leaks of the openssl but not one with so limited info.
Does anyone know if this memory leak is caused by libcrypto or false alarm of valgrind and is there any way to get additional info?
I have already seen this a few times. So far it was always a fault in my code. Because you shared no code, I can only give the latest issue in my case which caused this.
I was allocating a MAC code with the new OpenSSL 3 API with:
EVP_MAC *_mac = EVP_MAC_fetch(NULL, "cmac", NULL);
I forgot to deallocate this with:
EVP_MAC_free(_mac);

Extra allocs valgrind

Here is my valgrind output
$ valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes new
==14028== Memcheck, a memory error detector
==14028== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==14028== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==14028== Command: new
==14028==
allocated
deleted
==14028==
==14028== HEAP SUMMARY:
==14028== in use at exit: 72,704 bytes in 1 blocks
==14028== total heap usage: 2 allocs, 1 frees, 72,754 bytes allocated
==14028==
==14028== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==14028== at 0x4C29C23: malloc (vg_replace_malloc.c:299)
==14028== by 0x4EBF18F: pool (eh_alloc.cc:117)
==14028== by 0x4EBF18F: __static_initialization_and_destruction_0 (eh_alloc.cc:244)
==14028== by 0x4EBF18F: _GLOBAL__sub_I_eh_alloc.cc (eh_alloc.cc:307)
==14028== by 0x400FB02: _dl_init (in /usr/lib64/ld-2.17.so)
==14028== by 0x4001069: ??? (in /usr/lib64/ld-2.17.so)
==14028==
==14028== LEAK SUMMARY:
==14028== definitely lost: 0 bytes in 0 blocks
==14028== indirectly lost: 0 bytes in 0 blocks
==14028== possibly lost: 0 bytes in 0 blocks
==14028== still reachable: 72,704 bytes in 1 blocks
==14028== suppressed: 0 bytes in 0 blocks
==14028==
==14028== For counts of detected and suppressed errors, rerun with: -v
==14028== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
As you can see the extra alloc seems to be from some source I can't identify, valgrind lists it as ???. Is this just some weird allocation behind the scenes? Should I worry about it?
This allocation/'still reachable' memory report is normal, and has been reported on valgrind bugzilla (and fixed) : see a.o. bugs https://bugs.kde.org/show_bug.cgi?id=345307 and https://bugs.kde.org/show_bug.cgi?id=348978.
You might need to upgrade to a newer valgrind and/or newer ld/glibc/... to have all that fixed.
If you cannot upgrade yet, in the meantime, you can use a suppression file.
Run valgrind + your program with the valgrind option --gen-suppressions=yes (or =all) to provide the needed suppression entry.

Valgrind memcheck does not show source file

I'm investigating memory leak problems in a C++ application running on an embedded linux system (Yocto 1.5) with an ARM CPU.
Valgrind 3.8.1 is installed on the target.
The C++ program is compiled with gcc 4.8 with -g and -Og and is not stripped.
I've launched valgrind with the command below:
$ valgrind --tool=memcheck --leak-check=full /tmp/e3event-daemon -c /etc/e3event-daemon/config.json
Output of valgrind:
==7035== Memcheck, a memory error detector
==7035== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==7035== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==7035== Command: /tmp/e3event-daemon -c /etc/e3event-daemon/config.json
==7035==
==7035==
==7035== HEAP SUMMARY:
==7035== in use at exit: 4 bytes in 1 blocks
==7035== total heap usage: 421 allocs, 420 frees, 148,246 bytes allocated
==7035==
==7035== 4 bytes in 1 blocks are definitely lost in loss record 1 of 1
==7035== at 0x4834558: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==7035==
==7035== LEAK SUMMARY:
==7035== definitely lost: 4 bytes in 1 blocks
==7035== indirectly lost: 0 bytes in 0 blocks
==7035== possibly lost: 0 bytes in 0 blocks
==7035== still reachable: 0 bytes in 0 blocks
==7035== suppressed: 0 bytes in 0 blocks
==7035==
==7035== For counts of detected and suppressed errors, rerun with: -v
==7035== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
A memory leak is reported but a by 0x8048691: main (in ... line is missing. If I run the same program on my Ubuntu Linux machine (valgrind 3.10.1) I get this line which indicates where the problem is.
What should I do to get this by 0x8048691: main (in ... printed?