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_lock&) (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::domain[abi: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.
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_lock&) (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::domain[abi: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.