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.
Related
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.
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);
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?
valgrind prints the following diagnostic from an empty program:
$cat main.cpp
int main(){}
$g++ -std=c++1z -o main main.cpp
$valgrind --leak-check=full --show-leak-kinds=all ./main
==26823== Memcheck, a memory error detector
==26823== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==26823== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==26823== Command: ./main
==26823==
==26823==
==26823== HEAP SUMMARY:
==26823== in use at exit: 72,704 bytes in 1 blocks
==26823== total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
==26823==
==26823== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==26823== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26823== by 0x4E9D62F: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22)
==26823== by 0x4010109: call_init.part.0 (dl-init.c:78)
==26823== by 0x40101F2: call_init (dl-init.c:36)
==26823== by 0x40101F2: _dl_init (dl-init.c:126)
==26823== by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==26823==
==26823== LEAK SUMMARY:
==26823== definitely lost: 0 bytes in 0 blocks
==26823== indirectly lost: 0 bytes in 0 blocks
==26823== possibly lost: 0 bytes in 0 blocks
==26823== still reachable: 72,704 bytes in 1 blocks
==26823== suppressed: 0 bytes in 0 blocks
==26823==
==26823== For counts of detected and suppressed errors, rerun with: -v
==26823== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Notice how it states:
"total heap usage: 1 allocs, 0 frees".
It is consistently off by 1 for programs where I also allocate and manage memory properly. This seems to be an issue with the lib standard itself? How can I fix this? I can't seem to find a compiler flag to prevent this.
I have the same issue using the clang++ frontend.
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.