Valgrind 在 c++ 应用程序中报告与 CRYPTO_zalloc 相关的 memory 泄漏，但没有其他信息

Question

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?

Answer 1

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);