Hello, We have a target machine which is an arm 32-bit Android device. And we tried to check the leaks on some essential services for our product. So we choose the Valgrind for our kind of testing. But before proceeding, we want to test the one sample application with memory leaks in it. And run the application on top Valgrind in-arm devices but the leaks were not detected through the Valgrind. Can anyone help me out with this issue? Test Application:- #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> int leak_func(void){ char *ptr = NULL; ptr = (char *) calloc(1,20); ptr = "Hello World\n"; printf("%s \n",ptr); return 0; } int main(void){ int i=1; printf("%s: Invoked\n",__func__); leak_func(); while(i++) sleep(1); return 0; } compiled and pushed the above memory leak application into the arm platform device. #valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --show-reachable=yes --track-fds=yes --trace-children=yes --track-origins=yes --smc-check=all --extra-debug-info-path=path --log-file=/data/local/data.txt -v /system/bin/<memory Leak app> Observations:- the leaks were not detected with Valgrind. ==10143== ==10143== LEAK SUMMARY: ==10143== definitely lost: 0 bytes in 0 blocks ==10143== indirectly lost: 0 bytes in 0 blocks ==10143== possibly lost: 48 bytes in 1 block ==10143== still reachable: 14,843 bytes in 40 blocks ==10143== suppressed: 0 bytes in 0 blocks ==10143== SOFTWARE/OS VERSIONS Host machine Linux:- Linux 5.14.0-1054-oem #61-Ubuntu SMP Fri Oct 14 13:05:50 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux Target machine:-Linux Version = 3.4.0
> Observations:- > the leaks were not detected with Valgrind. You say no leaks were detected > ==10143== possibly lost: 48 bytes in 1 block > ==10143== still reachable: 14,843 bytes in 40 blocks And then Valgrind says that it detected 1 possible leak and 40 still reachable blocks. You need to look more closely at the leak details to tell whether your calloc really wasn't detected as a leak. You should also use a more recent Valgrind. 3.13 is old.
Created attachment 154858 [details] valgrind report Yes true. But the leak is a direct leak and should come under "definitely lost" not "possibly lost". Possibly lost:- ==10143== 48 bytes in 1 blocks are possibly lost in loss record 31 of 41 ==10143== at 0x481E1F0: malloc (vg_replace_malloc.c:298) ==10143== by 0x4CB17B5: android::SharedBuffer::alloc(unsigned int) (in /system/lib/libutils.so) ==10143== by 0x4CB3D65: android::VectorImpl::_grow(unsigned int, unsigned int) (in /system/lib/libutils.so) ==10143== by 0x4CB3DF7: android::VectorImpl::insertAt(void const*, unsigned int, unsigned int) (in /system/lib/libutils.so) ==10143== by 0x4CB426D: android::add_sysprop_change_callback(void (*)(), int) (in /system/lib/libutils.so) ==10143== by 0x40015B9: __dl__ZN6soinfo12CallFunctionEPKcPFvvE (in /system/bin/linker) and for this example, the possible leak is not pointing to the exact application leak. and if I ran the same application in the x86_64 platform it's showing an accurate leak. Report for the Same application on the X86_64 platform:- $ Valgrind ./a.out ==468067== Memcheck, a memory error detector ==468067== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==468067== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==468067== Command: ./a.out ==468067== main: Invoked Hello World ^C==468067== ==468067== Process terminating with default action of signal 2 (SIGINT) ==468067== at 0x49461B4: clock_nanosleep@@GLIBC_2.17 (clock_nanosleep.c:78) ==468067== by 0x494BEC6: nanosleep (nanosleep.c:27) ==468067== by 0x494BDFD: sleep (sleep.c:55) ==468067== by 0x109215: main (in /home/My-Space/Kernel_Test/Leak_Test/a.out) ==468067== ==468067== HEAP SUMMARY: ==468067== in use at exit: 20 bytes in 1 blocks ==468067== total heap usage: 2 allocs, 1 frees, 1,044 bytes allocated ==468067== ==468067== LEAK SUMMARY: ==468067== definitely lost: 20 bytes in 1 blocks ==468067== indirectly lost: 0 bytes in 0 blocks ==468067== possibly lost: 0 bytes in 0 blocks ==468067== still reachable: 0 bytes in 0 blocks ==468067== suppressed: 0 bytes in 0 blocks ==468067== Rerun with --leak-check=full to see details of leaked memory ==468067== ==468067== For lists of detected and suppressed errors, rerun with: -s ==468067== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ----------------------------------------------------------------------------------- Yes, I tried the latest Valgrind versions 3.16,3.17,3.19, and 3.20. But the Leak summary is not generating for ARM (32bit) android devices. Any solution for this issue?
OK, next thing, make sure that your heap memory really is being allocated. You have ptr = (char *) calloc(1,20); ptr = "Hello World\n"; I'm not sure if it is intentional to overwrite the 'ptr' pointer. (And you shouldn't cast the return value of calloc in C, unlike C++). Just using 'volatile char* ptr = strdup("Hello World\n");' should be sufficient, with the volatile to try to prevent the compiler from optimizing away 'ptr'. Can you check with a debugger to see if the memory really does get allocated?
Verified with the changes as you mention, leaks get detected under definitely lost of Leak Summary. But not shows the exact function name (leak_func ) where the leak happened in the application. Code Snippet:- int leak_func(void){ /* char *ptr = NULL; ptr = (char *) calloc(1,20); ptr = "Hello World\n"; */ volatile char* ptr = strdup("Hello World\n"); printf("%s \n",ptr); return 0; } ==23123== 13 bytes in 1 block are definitely lost in loss record 18 of 42 ==23123== at 0x481E1F0: malloc (vg_replace_malloc.c:298) ==23123== by 0x4866DFF: strdup (in /system/lib/libc.so) ==23123== ==23123== LEAK SUMMARY: ==23123== definitely lost: 13 bytes in 1 blocks ==23123== indirectly lost: 0 bytes in 0 blocks ==23123== possibly lost: 48 bytes in 1 blocks ==23123== still reachable: 14,843 bytes in 40 blocks ==23123== suppressed: 0 bytes in 0 blocks execution:- $valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --show-reachable=yes --track-fds=yes --trace-children=yes --track-origins=yes --smc-check=all --extra-debuginfo-path=path --demangle=yes --num-callers=20 --show-below-main=yes --log-file=/data/local/data.txt -v /system/bin/leak-test any thoughts?
(In reply to Raju Ponnagani from comment #4) > Verified with the changes as you mention, leaks get detected under > definitely lost of Leak Summary. But not shows the exact function name > (leak_func ) where the leak happened in the application. I can't comment on the callstack as I don't use ARM or Android. As I said earlier, the compiler is probably be optimizing away the call to calloc. When you do this ptr = "Hello World\n"; it doesn't copy the string into the memory pointed to by 'ptr'. Instead is puts the address of the read-only string "Hello World\n" into ptr. It also sees that the memory allocated by calloc is never used and can optimize it away. On FreeBSD 13.1 amd64 with clang 13 I also get no leak. objdump shows no call to calloc paulf> objdump --disassemble=leak_func ./463514 ./463514: file format elf64-x86-64-freebsd Disassembly of section .text: 0000000000201920 <leak_func>: 201920: 55 push %rbp 201921: 48 89 e5 mov %rsp,%rbp 201924: bf 80 05 20 00 mov $0x200580,%edi 201929: be 85 05 20 00 mov $0x200585,%esi 20192e: 31 c0 xor %eax,%eax 201930: e8 eb 00 00 00 call 201a20 <printf@plt> 201935: 31 c0 xor %eax,%eax 201937: 5d pop %rbp 201938: c3 ret
Hello Paul Floyd, I tried the same leak application with Valgrind 3.20 version in android(arm32 bit architecture) and this time the leaked summary is not generated. please check the below report. Valgrind command execution:- valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --show-reachable=yes --track-fds=yes --trace-children=yes --track-origins=yes --smc-check=all --extra-debuginfo-path=path --fullpath-after=string --demangle=yes --num-callers=20 --show-below-main=yes --log-file=/data/local/data.txt -v /system/bin/leak-test Report:- ==28938== Memcheck, a memory error detector ==28938== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==28938== Using Valgrind-3.20.0-5147d671e4-20221024 and LibVEX; rerun with -h for copyright info ==28938== Command: /system/bin/leak_test ==28938== Parent PID: 28901 ==28938== --28938-- --28938-- Valgrind options: --28938-- --tool=memcheck --28938-- --leak-check=full --28938-- --show-leak-kinds=all --28938-- --show-reachable=yes --28938-- --track-fds=yes --28938-- --trace-children=yes --28938-- --track-origins=yes --28938-- --smc-check=all --28938-- --extra-debuginfo-path=path --28938-- --fullpath-after=string --28938-- --demangle=yes --28938-- --num-callers=20 --28938-- --show-below-main=yes --28938-- --log-file=/data/local/data.txt --28938-- -v --28938-- Contents of /proc/version: --28938-- Linux version 3.4.0 (gcc version 4.8 (GCC) ) #30 SMP PREEMPT Thu Dec 15 15:14:11 EST 2022 --28938-- --28938-- Arch and hwcaps: ARM, LittleEndian, ARMv7-neon-vfp --28938-- Page sizes: currently 4096, max supported 4096 --28938-- Valgrind library directory: /data/local/Inst/libexec/valgrind --28938-- Reading syms from /system/bin/leak_test --28938-- Reading syms from /system/bin/linker --28938-- Considering /system/bin/linker .. --28938-- .. CRC mismatch (computed 777f94b8 wanted 1dd615cc) --28938-- Reading syms from /data/local/Inst/libexec/valgrind/memcheck-arm-linux --28938-- object doesn't have a dynamic symbol table --28938-- Scheduler: using generic scheduler lock implementation. --28938-- Reading suppressions file: /data/local/Inst/libexec/valgrind/default.supp --28938-- Reading syms from /data/local/Inst/libexec/valgrind/vgpreload_core-arm-linux.so --28938-- Discarding syms at 0x481a260-0x481a398 in /data/local/Inst/libexec/valgrind/vgpreload_core-arm-linux.so (have_dinfo 1) --28938-- Reading syms from /data/local/Inst/libexec/valgrind/vgpreload_memcheck-arm-linux.so --28938-- REDIR: 0x4009fe5 (NONE:__dl_strrchr) redirected to 0x4826ee0 (__dl_strrchr) --28938-- REDIR: 0x4008959 (NONE:__dl_strlen) redirected to 0x4827388 (__dl_strlen) --28938-- REDIR: 0x4007da4 (NONE:__dl_strcmp) redirected to 0x48279c0 (__dl_strcmp) --28938-- Discarding syms at 0x481fe7c-0x482db80 in /data/local/Inst/libexec/valgrind/vgpreload_memcheck-arm-linux.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libsigchain.so --28938-- Considering /system/lib/libsigchain.so .. --28938-- .. CRC mismatch (computed 56ff2ace wanted d7b20e71) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 7 available --28938-- Reading EXIDX entries: 6 attempted, 6 successful --28938-- Discarding syms at 0x4830484-0x48305d0 in /system/lib/libsigchain.so (have_dinfo 1) --28938-- Reading syms from /system/vendor/lib/libNimsWrap.so --28938-- Considering /system/vendor/lib/libNimsWrap.so .. --28938-- .. CRC mismatch (computed 2f87d97c wanted 719428bd) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 22 available --28938-- Reading EXIDX entries: 20 attempted, 20 successful --28938-- Discarding syms at 0x4833844-0x4833f24 in /system/vendor/lib/libNimsWrap.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libc.so --28938-- Considering /system/lib/libc.so .. --28938-- .. CRC mismatch (computed d578c1c7 wanted 3b7de796) --28938-- Discarding syms at 0x4844c20-0x487b6d4 in /system/lib/libc.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libcrypto.so --28938-- Considering /system/lib/libcrypto.so .. --28938-- .. CRC mismatch (computed 25f3fd67 wanted 3b07abe0) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 2672 available --28938-- Reading EXIDX entries: 2670 attempted, 2670 successful --28938-- Discarding syms at 0x48ccd80-0x495187c in /system/lib/libcrypto.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libcutils.so --28938-- Considering /system/lib/libcutils.so .. --28938-- .. CRC mismatch (computed 9380ca99 wanted 4855d956) --28938-- object doesn't have a symbol table --28938-- Discarding syms at 0x4992ba8-0x49980c8 in /system/lib/libcutils.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libm.so --28938-- Considering /system/lib/libm.so .. --28938-- .. CRC mismatch (computed c9ae47ad wanted 4577cdad) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 141 available ==28938== Warning: whilst reading EXIDX: ExtabEntryDecode: failed with error code: -10 ==28938== Warning: whilst reading EXIDX: ExtabEntryDecode: failed with error code: -10 --28938-- Reading EXIDX entries: 140 attempted, 138 successful --28938-- Discarding syms at 0x499e418-0x49aef8c in /system/lib/libm.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libsqlite.so --28938-- Considering /system/lib/libsqlite.so .. --28938-- .. CRC mismatch (computed a4ded485 wanted 1ff90107) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 1205 available --28938-- Reading EXIDX entries: 1203 attempted, 1203 successful --28938-- Discarding syms at 0x49b9308-0x4a0367c in /system/lib/libsqlite.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libssl.so --28938-- Considering /system/lib/libssl.so .. --28938-- .. CRC mismatch (computed 11ac8cb2 wanted 6b0790f0) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 419 available --28938-- Reading EXIDX entries: 418 attempted, 418 successful --28938-- Discarding syms at 0x4a21e90-0x4a458d4 in /system/lib/libssl.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libstdc++.so --28938-- Considering /system/lib/libstdc++.so .. --28938-- .. CRC mismatch (computed 4d059f2f wanted 3e50d7ce) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 17 available --28938-- Reading EXIDX entries: 16 attempted, 16 successful --28938-- Reading syms from /system/lib/liblog.so --28938-- Considering /system/lib/liblog.so .. --28938-- .. CRC mismatch (computed cc638156 wanted 9cb84a85) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 56 available --28938-- Reading EXIDX entries: 55 attempted, 55 successful --28938-- Discarding syms at 0x4a59884-0x4a5b9f0 in /system/lib/liblog.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libicui18n.so --28938-- Considering /system/lib/libicui18n.so .. --28938-- .. CRC mismatch (computed 634fe702 wanted 95dcf877) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 3398 available --28938-- Reading EXIDX entries: 3396 attempted, 3396 successful --28938-- Discarding syms at 0x4abf2f0-0x4b8a97a in /system/lib/libicui18n.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libicuuc.so --28938-- Considering /system/lib/libicuuc.so .. --28938-- .. CRC mismatch (computed 5349f35b wanted b69abf91) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 2061 available --28938-- Reading EXIDX entries: 2059 attempted, 2059 successful --28938-- Discarding syms at 0x4bda248-0x4c63538 in /system/lib/libicuuc.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libutils.so --28938-- Considering /system/lib/libutils.so .. --28938-- .. CRC mismatch (computed d649f5e6 wanted bd0b4d32) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 367 available --28938-- Reading EXIDX entries: 365 attempted, 365 successful --28938-- Discarding syms at 0x4cb7940-0x4cbe4d8 in /system/lib/libutils.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libgabi++.so --28938-- Considering /system/lib/libgabi++.so .. --28938-- .. CRC mismatch (computed 4b225222 wanted ca51215e) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 20 available --28938-- Reading EXIDX entries: 19 attempted, 19 successful --28938-- Discarding syms at 0x4cc5bd4-0x4cc60bc in /system/lib/libgabi++.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libstlport.so --28938-- Considering /system/lib/libstlport.so .. --28938-- .. CRC mismatch (computed 38d3de9e wanted 4db8a9f5) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 666 available --28938-- Reading EXIDX entries: 664 attempted, 664 successful --28938-- Discarding syms at 0x4ce0838-0x4cf7a6c in /system/lib/libstlport.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libbacktrace.so --28938-- Considering /system/lib/libbacktrace.so .. --28938-- .. CRC mismatch (computed 220400db wanted 81a4bbb4) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 76 available --28938-- Reading EXIDX entries: 75 attempted, 75 successful --28938-- Discarding syms at 0x4d01b0c-0x4d03f00 in /system/lib/libbacktrace.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libgccdemangle.so --28938-- Considering /system/lib/libgccdemangle.so .. --28938-- .. CRC mismatch (computed bb3fd709 wanted cdded923) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 43 available --28938-- Reading EXIDX entries: 42 attempted, 42 successful --28938-- Discarding syms at 0x4d07b1c-0x4d0a2c4 in /system/lib/libgccdemangle.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libunwind.so --28938-- Considering /system/lib/libunwind.so .. --28938-- .. CRC mismatch (computed e05cc3eb wanted 0e88d74a) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 168 available --28938-- Reading EXIDX entries: 167 attempted, 167 successful --28938-- Discarding syms at 0x4d0ff0c-0x4d18948 in /system/lib/libunwind.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libunwind-ptrace.so --28938-- Considering /system/lib/libunwind-ptrace.so .. --28938-- .. CRC mismatch (computed a158cc0e wanted 628240bd) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 13 available --28938-- Reading EXIDX entries: 12 attempted, 12 successful --28938-- Discarding syms at 0x4d62738-0x4d62ccc in /system/lib/libunwind-ptrace.so (have_dinfo 1) --28938-- Reading syms from /system/lib/libnetd_client.so --28938-- Considering /system/lib/libnetd_client.so .. --28938-- .. CRC mismatch (computed 2ea1119b wanted da1aba76) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 19 available --28938-- Reading EXIDX entries: 18 attempted, 18 successful --28938-- Discarding syms at 0x4d867ec-0x4d86eec in /system/lib/libnetd_client.so (have_dinfo 1) --28938-- Reading syms from /system/vendor/lib/libvendorconn.so --28938-- Considering /system/vendor/lib/libvendorconn.so .. --28938-- .. CRC mismatch (computed 82c5eb39 wanted dde4fe6d) --28938-- object doesn't have a symbol table --28938-- Reading EXIDX entries: 42 available --28938-- Reading EXIDX entries: 40 attempted, 40 successful disInstr(arm): unhandled instruction: 0xEC510F1E cond=14(0xE) 27:20=197(0xC5) 4:4=1 3:0=14(0xE) ==28938== valgrind: Unrecognised instruction at address 0x48d0bc8. ==28938== at 0x48D0BC8: ??? (in /system/lib/libcrypto.so) ==28938== Your program just tried to execute an instruction that Valgrind ==28938== did not recognise. There are two possible reasons for this. ==28938== 1. Your program has a bug and erroneously jumped to a non-code ==28938== location. If you are running Memcheck and you just saw a ==28938== warning about a bad jump, it's probably your program's fault. ==28938== 2. The instruction is legitimate but Valgrind doesn't handle it, ==28938== i.e. it's Valgrind's fault. If you think this is the case or ==28938== you are not sure, please let us know and we'll try to fix it. ==28938== Either way, Valgrind will now raise a SIGILL signal which will ==28938== probably kill your program. ==28938== ==28938== Process terminating with default action of signal 2 (SIGINT) ==28938== at 0x4870310: ??? (in /system/lib/libc.so) ==28938== ==28938== FILE DESCRIPTORS: 6 open (3 std) at exit. ==28938== Open AF_UNIX socket 10: /dev/socket/adbd ==28938== <inherited from parent> ==28938== ==28938== Open file descriptor 9: /dev/__properties__ ==28938== <inherited from parent> ==28938== ==28938== Open file descriptor 3: /data/local/data.txt ==28938== <inherited from parent> ==28938== ==28938== ==28938== HEAP SUMMARY: ==28938== in use at exit: 0 bytes in 0 blocks ==28938== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==28938== ==28938== All heap blocks were freed -- no leaks are possible ==28938== ==28938== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Not only for leak-test Leak Summary is not generating for any other services in the android arm platform.
disInstr(arm): unhandled instruction: 0xEC510F1E cond=14(0xE) 27:20=197(0xC5) 4:4=1 3:0=14(0xE) ==28938== valgrind: Unrecognised instruction at address 0x48d0bc8. ==28938== at 0x48D0BC8: ??? (in /system/lib/libcrypto.so) ^^^ says it all Try with as few options as possible.
Is this still an issue?
(In reply to m from comment #8) > Is this still an issue? Memcheck not detecting leaks for allocations that the compiler optimizes away was never an issue. Unreproducible errors that don't get more information after over 6 months are also, in my opinion a waste of our time.
Ok, if the issue is not-a-bug/inactive/unreproducible mind closing it for now to avoid it showing up in the search results of open issues? If there is a minimal code to reproduce the issue reliably on the latest version of valgrind, I guess it can be reopened or a new issue opened.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!