Valgrind always has 5 blocks still reachable

[Keyun-Istil]

When I used Valgrind for memory checks I found that there were always five blocks of memory that were still reachable, and this would also be the case with the samples/icehello/iox-cpp-publisher-helloworld. Is there any good way to eliminate this?

LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 1,812 bytes in 5 blocks
suppressed: 0 bytes in 0 blocks

[elBoberido]

@Keyun-Istil is it the same amount of blocks an bytes all the time?

I think we need to investigate where this comes from. Are you able to reproduce this with the leak sanitizer? This might give us some hints where to look.

Leaked but still reachable would be something like this

int main() {
    auto foo = new int{42};
    return *foo;
}

Not nice but in general also not a big problem since the memory will be reclaimed by the OS when the process exits. Definite losses like the following would be problematic though

void foo() {
    for(int i = 0; i < 42; ++i) {
        new int {i};
    }
}

int main() {
    foo();
    foo();
    return 0;
}

Anyway, if you have the chance to check this with the leak sanitizer it would be quite helpful for us.

[elBoberido]

I had a closer look and I think these are either false positives or comes from external lib. The only warning which originates from iceoryx itself is related to the getgrouplist call and from my understanding this is a false positive. @elfenpiff could you please confirm?

The lead sanitizer did no issue any warning.

Also, my example for leaked but still reachable was wrong and both, the address sanitizer and valgrind report leaks on that example.

This is the output from valgrind --leak-check=full --show-leak-kinds=all -s ./iox-cpp-publisher-helloworld with everything but iox::runtime::PoshRuntime::initRuntime(APP_NAME); removed from the iox_publisher_helloworld.cpp.

==23559== Memcheck, a memory error detector
==23559== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==23559== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==23559== Command: ./iox-cpp-publisher-helloworld
==23559== 
==23559== 
==23559== HEAP SUMMARY:
==23559==     in use at exit: 1,872 bytes in 5 blocks
==23559==   total heap usage: 389 allocs, 384 frees, 341,603 bytes allocated
==23559== 
==23559== 42 bytes in 1 blocks are still reachable in loss record 1 of 5
==23559==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==23559==    by 0x40271FF: malloc (rtld-malloc.h:56)
==23559==    by 0x40271FF: strdup (strdup.c:42)
==23559==    by 0x4016A66: _dl_load_cache_lookup (dl-cache.c:527)
==23559==    by 0x400A981: _dl_map_object (dl-load.c:2193)
==23559==    by 0x400E9A8: dl_open_worker_begin (dl-open.c:534)
==23559==    by 0x4C30C27: _dl_catch_exception (dl-error-skeleton.c:208)
==23559==    by 0x400DF99: dl_open_worker (dl-open.c:782)
==23559==    by 0x4C30C27: _dl_catch_exception (dl-error-skeleton.c:208)
==23559==    by 0x400E34D: _dl_open (dl-open.c:883)
==23559==    by 0x4C30F90: do_dlopen (dl-libc.c:95)
==23559==    by 0x4C30C27: _dl_catch_exception (dl-error-skeleton.c:208)
==23559==    by 0x4C30CF2: _dl_catch_error (dl-error-skeleton.c:227)
==23559== 
==23559== 42 bytes in 1 blocks are still reachable in loss record 2 of 5
==23559==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==23559==    by 0x400DD20: malloc (rtld-malloc.h:56)
==23559==    by 0x400DD20: _dl_new_object (dl-object.c:199)
==23559==    by 0x4008C82: _dl_map_object_from_fd (dl-load.c:1063)
==23559==    by 0x400A600: _dl_map_object (dl-load.c:2327)
==23559==    by 0x400E9A8: dl_open_worker_begin (dl-open.c:534)
==23559==    by 0x4C30C27: _dl_catch_exception (dl-error-skeleton.c:208)
==23559==    by 0x400DF99: dl_open_worker (dl-open.c:782)
==23559==    by 0x4C30C27: _dl_catch_exception (dl-error-skeleton.c:208)
==23559==    by 0x400E34D: _dl_open (dl-open.c:883)
==23559==    by 0x4C30F90: do_dlopen (dl-libc.c:95)
==23559==    by 0x4C30C27: _dl_catch_exception (dl-error-skeleton.c:208)
==23559==    by 0x4C30CF2: _dl_catch_error (dl-error-skeleton.c:227)
==23559== 
==23559== 72 bytes in 1 blocks are still reachable in loss record 3 of 5
==23559==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==23559==    by 0x4013E4D: malloc (rtld-malloc.h:56)
==23559==    by 0x4013E4D: allocate_dtv_entry (dl-tls.c:684)
==23559==    by 0x4013E4D: allocate_and_init (dl-tls.c:709)
==23559==    by 0x4013E4D: tls_get_addr_tail (dl-tls.c:907)
==23559==    by 0x401826B: __tls_get_addr (tls_get_addr.S:55)
==23559==    by 0x91656A3: _nss_systemd_is_blocked (in /usr/lib/x86_64-linux-gnu/libnss_systemd.so.2)
==23559==    by 0x916F9CE: _nss_systemd_initgroups_dyn (in /usr/lib/x86_64-linux-gnu/libnss_systemd.so.2)
==23559==    by 0x4BA3360: internal_getgrouplist (initgroups.c:101)
==23559==    by 0x4BA35AB: getgrouplist (initgroups.c:156)
==23559==    by 0x16B018: iox_getgrouplist(char const*, unsigned int, unsigned int*, int*) (grp.cpp:22)
==23559==    by 0x1502A6: iox::posix::PosixCallBuilder<int, char const*, unsigned int, unsigned int*, int*>::operator()(char const*, unsigned int, unsigned int*, int*) && (posix_call.inl:100)
==23559==    by 0x14EA31: iox::posix::PosixUser::getGroups() const (posix_access_rights.cpp:154)
==23559==    by 0x11FF73: iox::mepoo::SegmentManager<iox::mepoo::MePooSegment<iox::posix::SharedMemoryObject, iox::mepoo::MemoryManager> >::getSegmentMappings(iox::posix::PosixUser const&) (segment_manager.inl:55)
==23559==    by 0x11ECB1: iox::runtime::SharedMemoryUser::openDataSegments(unsigned long, unsigned long) (shared_memory_user.cpp:69)
==23559== 
==23559== 504 bytes in 1 blocks are still reachable in loss record 4 of 5
==23559==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==23559==    by 0x40162DC: calloc (rtld-malloc.h:44)
==23559==    by 0x40162DC: _dl_check_map_versions (dl-version.c:273)
==23559==    by 0x400ED13: dl_open_worker_begin (dl-open.c:600)
==23559==    by 0x4C30C27: _dl_catch_exception (dl-error-skeleton.c:208)
==23559==    by 0x400DF99: dl_open_worker (dl-open.c:782)
==23559==    by 0x4C30C27: _dl_catch_exception (dl-error-skeleton.c:208)
==23559==    by 0x400E34D: _dl_open (dl-open.c:883)
==23559==    by 0x4C30F90: do_dlopen (dl-libc.c:95)
==23559==    by 0x4C30C27: _dl_catch_exception (dl-error-skeleton.c:208)
==23559==    by 0x4C30CF2: _dl_catch_error (dl-error-skeleton.c:227)
==23559==    by 0x4C310C6: dlerror_run (dl-libc.c:45)
==23559==    by 0x4C310C6: __libc_dlopen_mode (dl-libc.c:162)
==23559==    by 0x4C11299: module_load (nss_module.c:191)
==23559== 
==23559== 1,212 bytes in 1 blocks are still reachable in loss record 5 of 5
==23559==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==23559==    by 0x400DA02: calloc (rtld-malloc.h:44)
==23559==    by 0x400DA02: _dl_new_object (dl-object.c:92)
==23559==    by 0x4008C82: _dl_map_object_from_fd (dl-load.c:1063)
==23559==    by 0x400A600: _dl_map_object (dl-load.c:2327)
==23559==    by 0x400E9A8: dl_open_worker_begin (dl-open.c:534)
==23559==    by 0x4C30C27: _dl_catch_exception (dl-error-skeleton.c:208)
==23559==    by 0x400DF99: dl_open_worker (dl-open.c:782)
==23559==    by 0x4C30C27: _dl_catch_exception (dl-error-skeleton.c:208)
==23559==    by 0x400E34D: _dl_open (dl-open.c:883)
==23559==    by 0x4C30F90: do_dlopen (dl-libc.c:95)
==23559==    by 0x4C30C27: _dl_catch_exception (dl-error-skeleton.c:208)
==23559==    by 0x4C30CF2: _dl_catch_error (dl-error-skeleton.c:227)
==23559== 
==23559== LEAK SUMMARY:
==23559==    definitely lost: 0 bytes in 0 blocks
==23559==    indirectly lost: 0 bytes in 0 blocks
==23559==      possibly lost: 0 bytes in 0 blocks
==23559==    still reachable: 1,872 bytes in 5 blocks
==23559==         suppressed: 0 bytes in 0 blocks
==23559== 
==23559== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)