title: Valgrind reports memory leak related with CRYPTO_zalloc in a c++ app but no additional info
body: <p>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.</p>
  
  <p>When I run the valgrind with the following arguments:</p>
  
  <pre><code>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
  </code></pre>
  
  <p>I get the following error message :</p>
  
  <pre><code>==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)
  </code></pre>
  
  <p>Since I've dealt with similar problems when using gdb I gave <code>export OPENSSL_armcap=0</code> and then I got the following:</p>
  
  <pre><code>==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)
  </code></pre>
  
  <p>However no additional info was retrieved even though I've compiled the code with <code>-ggdb3</code>.<br>
  The info that I get from <code>openssl version -a</code> is:</p>
  
  <pre><code>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"
  </code></pre>
  
  <p>I've found several issues regarding memory leaks of the openssl but not one with so limited info.<br>
  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?</p>