Running Valgrind: False positives

Question

I am trying to set up Valgrind to detect possible leaks from the native part of an app.

I have managed to build and get it running on my device, but I seem to be getting an error, causing many leaks to be detected whatever I use it on.

Here is the output of me using valgrind on 'ls' (that should come up with 0 leaks):

130|root@hwALE-H:/data/local/Inst/bin # ./valgrind ls
==16610== Memcheck, a memory error detector
==16610== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16610== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==16610== Command: ls
==16610== 
WARNING: linker: /data/local/Inst/lib/valgrind/vgpreload_core-arm64-linux.so: unsupported flags DT_FLAGS_1=0x421
WARNING: linker: /data/local/Inst/lib/valgrind/vgpreload_memcheck-arm64-linux.so: unsupported flags DT_FLAGS_1=0x421
==16610== Invalid free() / delete / delete[] / realloc()
==16610==    at 0x487D7D4: free (vg_replace_malloc.c:530)
==16610==    by 0x40084FB: __dl__ZL12load_libraryilR10LinkedListI8LoadTask18TypeBasedAllocatorI15LinkedListEntryIS0_EEEPKciPK17android_dlextinfo (in /system/bin/linker64)
==16610==    by 0x40097AF: __dl__ZL14find_librariesP6soinfoPKPKcmPS0_PNSt3__16vectorIS0_NS6_9allocatorIS0_EEEEmiPK17android_dlextinfo (in /system/bin/linker64)
==16610==    by 0x400A883: __dl___linker_init (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==  Address 0x4039150 is in a rw- anonymous segment
==16610== 
==16610== Invalid free() / delete / delete[] / realloc()
==16610==    at 0x487D7D4: free (vg_replace_malloc.c:530)
==16610==    by 0x4009A43: __dl__ZL14find_librariesP6soinfoPKPKcmPS0_PNSt3__16vectorIS0_NS6_9allocatorIS0_EEEEmiPK17android_dlextinfo (in /system/bin/linker64)
==16610==    by 0x400A883: __dl___linker_init (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==    by 0x40029EB: _start (in /system/bin/linker64)
==16610==  Address 0x403e010 is in a rw- anonymous segment
==16610== 
callgrind_annotate
callgrind_control
cg_annotate
cg_diff
cg_merge
ms_print
valgrind
valgrind-di-server
valgrind-listener
vgdb
==16610== 
==16610== HEAP SUMMARY:
==16610==     in use at exit: 680 bytes in 12 blocks
==16610==   total heap usage: 58 allocs, 48 frees, 72,870 bytes allocated
==16610== 
==16610== LEAK SUMMARY:
==16610==    definitely lost: 352 bytes in 7 blocks
==16610==    indirectly lost: 0 bytes in 0 blocks
==16610==      possibly lost: 16 bytes in 1 blocks
==16610==    still reachable: 312 bytes in 4 blocks
==16610==         suppressed: 0 bytes in 0 blocks
==16610== Rerun with --leak-check=full to see details of leaked memory
==16610== 
==16610== For counts of detected and suppressed errors, rerun with: -v
==16610== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

Any suggestions to help solve this issue will greatly appreciated!

EDIT: Here is the full logcat output from starting a "HelloJNI" type app, with a 6byte leak from native code. https://pastebin.com/j7TWC5Bu The trace is hardly usable.

Answer 1

My guess is that this is a deliberate "leak".

Looking at the addresses it looks like the link loader is using a "bump allocator" for malloc() based on a block of global memory. Since this malloc() isn't really using a heap there is no need to free the memory.