Valgrind 在 c++ 應用程序中報告與 CRYPTO_zalloc 相關的 memory 泄漏，但沒有其他信息

Question

我在 arm 嵌入式板中創建了一個 c++ 應用程序。該板使用 armbian linux debian 風格。 這個應用程序在 poco NetSSL 庫的幫助下在幾個地方執行 https 請求。

當我使用以下 arguments 運行 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 的 memory 泄漏的問題，但沒有一個信息如此有限。
有誰知道這個 memory 泄漏是由 libcrypto 還是 valgrind 的誤報引起的，有沒有辦法獲得更多信息？

Answer 1

我已經看過幾次了。 到目前為止，它始終是我的代碼中的錯誤。 因為您沒有共享任何代碼，所以我只能給出導致此問題的最新問題。

我正在使用新的 OpenSSL 3 API 分配一個 MAC 代碼：

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

我忘了用以下方法解除分配：

EVP_MAC_free(_mac);