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

Question

我在 Arm 嵌入式板上创建了一个 C++ 应用程序。该板使用 armbian linux debian 风格。这个应用程序在 poco NetSSl 库的帮助下在多个地方执行 https 请求。

当我使用以下参数运行 valgrind 时：

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

我收到以下错误消息：

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

因为我在使用 gdb 时处理过类似的问题，所以我给出了

export OPENSSL_armcap=0

，然后我得到了以下结果：

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

但是，即使我使用

-ggdb3

编译了代码，也没有检索到任何其他信息。
我从

openssl version -a

得到的信息是：

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"

我发现了几个有关 openssl 内存泄漏的问题，但信息如此有限。
有谁知道这个内存泄漏是否是由 libcrypto 或 valgrind 的误报引起的，有什么方法可以获取更多信息？

Answer 1

我已经看过几次了。到目前为止，这始终是我的代码中的错误。因为您没有共享代码，所以我只能给出我的案例中导致此问题的最新问题。

我使用新的 OpenSSL 3 API 分配 MAC 代码：

EVP_MAC *_mac = EVP_MAC_fetch(NULL, "cmac", NULL);

我忘记用以下命令取消分配：

EVP_MAC_free(_mac);