Memory Leak in cpprest library.

[Ansul501]

Hello,

I observed some memory leak in the cpprest library. I use the valgrind to detect the memory leaks.
Here are the logs that valgrind has generated.

==21408== Memcheck, a memory error detector
==21408== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==21408== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==21408== Command: ./sony-nmos-cpp-node
==21408== Parent PID: 20972
==21408==
disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E
==21408== valgrind: Unrecognised instruction at address 0x4d34967.
==21408== at 0x4D34966: ??? (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==21408== Your program just tried to execute an instruction that Valgrind
==21408== did not recognise. There are two possible reasons for this.
==21408== 1. Your program has a bug and erroneously jumped to a non-code
==21408== location. If you are running Memcheck and you just saw a
==21408== warning about a bad jump, it's probably your program's fault.
==21408== 2. The instruction is legitimate but Valgrind doesn't handle it,
==21408== i.e. it's Valgrind's fault. If you think this is the case or
==21408== you are not sure, please let us know and we'll try to fix it.
==21408== Either way, Valgrind will now raise a SIGILL signal which will
==21408== probably kill your program.
==21408==
==21408== Process terminating with default action of signal 2 (SIGINT)
==21408== at 0x4C62526: __libc_do_syscall (libc-do-syscall.S:47)
==21408== by 0x4C5D67D: futex_wait_cancelable (futex-internal.h:88)
==21408== by 0x4C5D67D: __pthread_cond_wait_common (pthread_cond_wait.c:502)
==21408== by 0x4C5D67D: pthread_cond_wait@@GLIBC_2.4 (pthread_cond_wait.c:655)
==21408== by 0x4F3D933: std::condition_variable::wait(std::unique_lockstd::mutex&) (in /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.25)
==21408==
==21408== HEAP SUMMARY:
==21408== in use at exit: 2,252,239 bytes in 43,798 blocks
==21408== total heap usage: 350,535 allocs, 306,737 frees, 12,109,434 bytes allocated
==21408==
==21408== 96 bytes in 1 blocks are definitely lost in loss record 12,212 of 13,524
==21408== at 0x483F5C8: malloc (vg_replace_malloc.c:299)
==21408== by 0x50BBA05: __libc_alloc_buffer_allocate (alloc_buffer_allocate.c:26)
==21408== by 0x51146DB: alloc_buffer_allocate (alloc_buffer.h:143)
==21408== by 0x51146DB: __resolv_conf_allocate (resolv_conf.c:411)
==21408== by 0x5112F0F: __resolv_conf_load (res_init.c:592)
==21408== by 0x511448D: __resolv_conf_get_current (resolv_conf.c:163)
==21408== by 0x51134B9: __res_vinit (res_init.c:614)
==21408== by 0x757EDF: web::hosts::experimental::domainabi:cxx11 (host_utils.cpp:52)
==21408== by 0x75817D: web::hosts::experimental::host_interfaces() (host_utils.cpp:212)
==21408== by 0x6D9DFF: nmos::details::insert_default_settings(web::json::value&, bool) (settings.cpp:44)
==21408== by 0x6DA547: nmos::insert_node_default_settings(web::json::value&) (settings.cpp:95)
==21408== by 0x18A083: main (main.cpp:71)
==21408==
==21408== LEAK SUMMARY:
==21408== definitely lost: 96 bytes in 1 blocks
==21408== indirectly lost: 0 bytes in 0 blocks
==21408== possibly lost: 463,221 bytes in 11,534 blocks
==21408== still reachable: 1,788,922 bytes in 32,263 blocks
==21408== of which reachable via heuristic:
==21408== multipleinheritance: 32 bytes in 1 blocks
==21408== suppressed: 0 bytes in 0 blocks
==21408== Reachable blocks (those to which a pointer was found) are not shown.
==21408== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==21408==
==21408== For counts of detected and suppressed errors, rerun with: -v
==21408== ERROR SUMMARY: 382 errors from 382 contexts (suppressed: 0 from 0)

I am observing definitely lost as well as possibly lost kind of leaks. Does anybody else also facing memory leak? As it is very low memory leak it wouldn't come up fast.