Created attachment 158821 [details] left is my x86 ubuntu 20.04 and right is arm linux STEPS TO REPRODUCE 1.folloing is my test code, and i use arm-linux-gnueabihf-gcc -g leak.c -o leak to compile it //leak.c #include <stdio.h> #include <stdlib.h> void func() { char *str = (char *)malloc(8); str[8] = 9; return; } int main() { int i = 1; int *p = (int *)malloc(100); printf("i : %d\n", i); func(); return 0; } 2.my gcc version output is Using built-in specs. COLLECT_GCC=arm-linux-gnueabihf-gcc gcc version 9.1.0 (GCC) 3. valgrind source code is download form https://sourceware.org/pub/valgrind/valgrind-3.21.0.tar.bz2, following is my compile process: ./autogen.sh ./configure --prefix=$output --host=arm-linux-gnueabihf make -j6 && sudo make install 4.then i upload all files that Valgrind depends on running to the arm linux,it can run successfully 5.finally i use ./valgrind --leak-check=full ./leak and vlagrind tips as follows ~ $ ./valgrind --leak-check=full ./leak 11111111111111111! toolfile : /home/admin/memcheck-arm-linux ==1581== Memcheck, a memory error detector ==1581== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==1581== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info ==1581== Command: ./leak ==1581== i : 1 test ok! ==1581== ==1581== HEAP SUMMARY: ==1581== in use at exit: 0 bytes in 0 blocks ==1581== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==1581== ==1581== All heap blocks were freed -- no leaks are possible ==1581== ==1581== For lists of detected and suppressed errors, rerun with: -s ==1581== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux version 4.9.84 (root@cx-System-Product-Name) (gcc version 9.1.0 (GCC) ) ADDITIONAL INFORMATION
This is the root cause: ==1581== total heap usage: 0 allocs, 0 frees, 0 bytes allocated The malloc and free calls are not being intercepted for some reason.
Could you run with --log-file=redir.log --trace-redir=yes and attech the resulting redir.log here please?
(In reply to Paul Floyd from comment #2) > Could you run with --log-file=redir.log --trace-redir=yes and attech the > resulting redir.log here please? sure,thanks for your reply i run with the ./valgrind --leak-check=full --log-file=redir.log --trace-redir=yes ./leak and followings is the log ==880== Memcheck, a memory error detector ==880== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==880== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info ==880== Command: ./leak ==880== Parent PID: 504 ==880== --880-- << --880-- ------ REDIR STATE after VG_(redir_initialise) ------ --880-- TOPSPECS of soname (hardwired) --880-- ld-linux-armhf.so.3 index RL-> (0000.0) 0x580ccdf0 --880-- ld-linux.so.3 index RL-> (0000.0) 0x580ccdf0 --880-- ld-linux-armhf.so.3 strcmp RL-> (0000.0) 0x580ccf34 --880-- ld-linux.so.3 strcmp RL-> (0000.0) 0x580ccf34 --880-- ld-linux-armhf.so.3 memcpy RL-> (0000.0) 0x580cce28 --880-- ld-linux.so.3 memcpy RL-> (0000.0) 0x580cce28 --880-- ld-linux-armhf.so.3 strlen RL-> (0000.0) 0x580ccdc4 --880-- ld-linux.so.3 strlen RL-> (0000.0) 0x580ccdc4 --880-- ------ ACTIVE ------ --880-- >> --880-- Reading syms from /home/admin/leak --880-- svma 0x00000103a8, avma 0x00000103a8 --880-- << --880-- ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------ --880-- TOPSPECS of soname NONE filename /home/admin/leak --880-- TOPSPECS of soname (hardwired) --880-- ld-linux-armhf.so.3 index RL-> (0000.0) 0x580ccdf0 --880-- ld-linux.so.3 index RL-> (0000.0) 0x580ccdf0 --880-- ld-linux-armhf.so.3 strcmp RL-> (0000.0) 0x580ccf34 --880-- ld-linux.so.3 strcmp RL-> (0000.0) 0x580ccf34 --880-- ld-linux-armhf.so.3 memcpy RL-> (0000.0) 0x580cce28 --880-- ld-linux.so.3 memcpy RL-> (0000.0) 0x580cce28 --880-- ld-linux-armhf.so.3 strlen RL-> (0000.0) 0x580ccdc4 --880-- ld-linux.so.3 strlen RL-> (0000.0) 0x580ccdc4 --880-- ------ ACTIVE ------ --880-- >> --880-- Reading syms from /lib/ld-2.30.so --880-- svma 0x0000000a40, avma 0x0004000a40 --880-- << --880-- ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------ --880-- TOPSPECS of soname ld-linux-armhf.so.3 filename /lib/ld-2.30.so --880-- TOPSPECS of soname NONE filename /home/admin/leak --880-- TOPSPECS of soname (hardwired) --880-- ld-linux-armhf.so.3 index RL-> (0000.0) 0x580ccdf0 --880-- ld-linux.so.3 index RL-> (0000.0) 0x580ccdf0 --880-- ld-linux-armhf.so.3 strcmp RL-> (0000.0) 0x580ccf34 --880-- ld-linux.so.3 strcmp RL-> (0000.0) 0x580ccf34 --880-- ld-linux-armhf.so.3 memcpy RL-> (0000.0) 0x580cce28 --880-- ld-linux.so.3 memcpy RL-> (0000.0) 0x580cce28 --880-- ld-linux-armhf.so.3 strlen RL-> (0000.0) 0x580ccdc4 --880-- ld-linux.so.3 strlen RL-> (0000.0) 0x580ccdc4 --880-- ------ ACTIVE ------ --880-- 0x04012521 (index ) R-> (0000.0) 0x580ccdf0 ??? --880-- 0x040125f1 (strcmp ) R-> (0000.0) 0x580ccf34 ??? --880-- 0x04012c01 (strlen ) R-> (0000.0) 0x580ccdc4 ??? --880-- 0x04013580 (memcpy ) R-> (0000.0) 0x580cce28 ??? --880-- >> --880-- Reading syms from /home/admin/memcheck-arm-linux --880-- svma 0x0058000100, avma 0x0058000100 --880-- << --880-- ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------ --880-- TOPSPECS of soname NONE filename /home/admin/memcheck-arm-linux --880-- TOPSPECS of soname ld-linux-armhf.so.3 filename /lib/ld-2.30.so --880-- TOPSPECS of soname NONE filename /home/admin/leak --880-- TOPSPECS of soname (hardwired) --880-- ld-linux-armhf.so.3 index RL-> (0000.0) 0x580ccdf0 --880-- ld-linux.so.3 index RL-> (0000.0) 0x580ccdf0 --880-- ld-linux-armhf.so.3 strcmp RL-> (0000.0) 0x580ccf34 --880-- ld-linux.so.3 strcmp RL-> (0000.0) 0x580ccf34 --880-- ld-linux-armhf.so.3 memcpy RL-> (0000.0) 0x580cce28 --880-- ld-linux.so.3 memcpy RL-> (0000.0) 0x580cce28 --880-- ld-linux-armhf.so.3 strlen RL-> (0000.0) 0x580ccdc4 --880-- ld-linux.so.3 strlen RL-> (0000.0) 0x580ccdc4 --880-- ------ ACTIVE ------ --880-- 0x04012521 (index ) R-> (0000.0) 0x580ccdf0 ??? --880-- 0x040125f1 (strcmp ) R-> (0000.0) 0x580ccf34 ??? --880-- 0x04012c01 (strlen ) R-> (0000.0) 0x580ccdc4 ??? --880-- 0x04013580 (memcpy ) R-> (0000.0) 0x580cce28 ??? --880-- >> --880-- REDIR: 0x4012c01 (ld-linux-armhf.so.3:strlen) redirected to 0x580ccdc4 (???) --880-- REDIR: 0x4013580 (ld-linux-armhf.so.3:memcpy) redirected to 0x580cce28 (???) --880-- REDIR: 0x40125f1 (ld-linux-armhf.so.3:strcmp) redirected to 0x580ccf34 (???) --880-- REDIR: 0x4012521 (ld-linux-armhf.so.3:index) redirected to 0x580ccdf0 (???) --880-- Reading syms from /home/admin/libexec/valgrind/vgpreload_core-arm-linux.so --880-- svma 0x0000000384, avma 0x000482a384 --880-- << --880-- ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------ --880-- TOPSPECS of soname NONE filename /home/admin/libexec/valgrind/vgpreload_core-arm-linux.so --880-- TOPSPECS of soname NONE filename /home/admin/memcheck-arm-linux --880-- TOPSPECS of soname ld-linux-armhf.so.3 filename /lib/ld-2.30.so --880-- TOPSPECS of soname NONE filename /home/admin/leak --880-- TOPSPECS of soname (hardwired) --880-- ld-linux-armhf.so.3 index RL-> (0000.0) 0x580ccdf0 --880-- ld-linux.so.3 index RL-> (0000.0) 0x580ccdf0 --880-- ld-linux-armhf.so.3 strcmp RL-> (0000.0) 0x580ccf34 --880-- ld-linux.so.3 strcmp RL-> (0000.0) 0x580ccf34 --880-- ld-linux-armhf.so.3 memcpy RL-> (0000.0) 0x580cce28 --880-- ld-linux.so.3 memcpy RL-> (0000.0) 0x580cce28 --880-- ld-linux-armhf.so.3 strlen RL-> (0000.0) 0x580ccdc4 --880-- ld-linux.so.3 strlen RL-> (0000.0) 0x580ccdc4 --880-- ------ ACTIVE ------ --880-- 0x04012521 (index ) R-> (0000.0) 0x580ccdf0 ??? --880-- 0x040125f1 (strcmp ) R-> (0000.0) 0x580ccf34 ??? --880-- 0x04012c01 (strlen ) R-> (0000.0) 0x580ccdc4 ??? --880-- 0x04013580 (memcpy ) R-> (0000.0) 0x580cce28 ??? --880-- >> --880-- Reading syms from /lib/libc-2.30.so --880-- svma 0x0000017200, avma 0x0004853200 --880-- << --880-- ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------ --880-- TOPSPECS of soname libc.so.6 filename /lib/libc-2.30.so --880-- TOPSPECS of soname NONE filename /home/admin/libexec/valgrind/vgpreload_core-arm-linux.so --880-- TOPSPECS of soname NONE filename /home/admin/memcheck-arm-linux --880-- TOPSPECS of soname ld-linux-armhf.so.3 filename /lib/ld-2.30.so --880-- TOPSPECS of soname NONE filename /home/admin/leak --880-- TOPSPECS of soname (hardwired) --880-- ld-linux-armhf.so.3 index RL-> (0000.0) 0x580ccdf0 --880-- ld-linux.so.3 index RL-> (0000.0) 0x580ccdf0 --880-- ld-linux-armhf.so.3 strcmp RL-> (0000.0) 0x580ccf34 --880-- ld-linux.so.3 strcmp RL-> (0000.0) 0x580ccf34 --880-- ld-linux-armhf.so.3 memcpy RL-> (0000.0) 0x580cce28 --880-- ld-linux.so.3 memcpy RL-> (0000.0) 0x580cce28 --880-- ld-linux-armhf.so.3 strlen RL-> (0000.0) 0x580ccdc4 --880-- ld-linux.so.3 strlen RL-> (0000.0) 0x580ccdc4 --880-- ------ ACTIVE ------ --880-- 0x04012521 (index ) R-> (0000.0) 0x580ccdf0 ??? --880-- 0x040125f1 (strcmp ) R-> (0000.0) 0x580ccf34 ??? --880-- 0x04012c01 (strlen ) R-> (0000.0) 0x580ccdc4 ??? --880-- 0x04013580 (memcpy ) R-> (0000.0) 0x580cce28 ??? --880-- >> ==880== ==880== HEAP SUMMARY: ==880== in use at exit: 0 bytes in 0 blocks ==880== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==880== ==880== All heap blocks were freed -- no leaks are possible ==880== ==880== For lists of detected and suppressed errors, rerun with: -s ==880== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) I also refer to this URL https://github.com/clearlinux/distribution/issues/119 There are some phenomena that are similar to what I have encountered now, but my code already contains the updates inside
Are using a statically linked C library?
You are not reading any symbols from /lib/libc-2.30.so Is it stripped? On amd64 'file' tells me file /usr/lib64/libc-2.17.so /usr/lib64/libc-2.17.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=fc4fa58e47a5acc137eadb7689bce4357c557a96, for GNU/Linux 2.6.32, not stripped Do you have a debuginfo package for libc? I looked at the GH link. It's true that Valgrind is quite sensitive to the PT_LOAD sections and only works with a limited number of variations.
It shouldn't be possible to strip libc.so in a way that removes a public symbol like malloc - it must at least be in the dynamic symbol table or the dynamic linker couldn't work.
(In reply to Tom Hughes from comment #6) > It shouldn't be possible to strip libc.so in a way that removes a public > symbol like malloc - it must at least be in the dynamic symbol table or the > dynamic linker couldn't work. Indeed. The redirs should still work. Stuff like stack walking and matching suppressions will be all messed up.
Indeed, after I uploaded libc-2.30.so in the /lib of arm linux to the local, and then i used the arm-linux-gnueabihf-nm command to read the symbol information in it and found that it was empty tu@ubuntu:~/Software/tmp$ arm-linux-gnueabihf-nm ./libc-2.30.so arm-linux-gnueabihf-nm: ./libc-2.30.so: no symbols following is my locak libc-2.30.so,whihc i also use nm tools to read it symobls tu@ubuntu:~/Software/2.toolchain/gcc-9.1.0-2019.11-x86_64_arm-linux-gnueabihf/gcc-sigmastar-9.1.0-2019.11-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/lib$ arm-linux-gnueabihf-nm ./libc-2.30.so > ~/Software/tmp/test.s The test.s file contains basic sybmols ------------ 3572 000568c4 t __mallinfo 3573 000568c4 W mallinfo 3574 000559ec t __malloc 3575 000559ec T malloc 3576 00055f2c t __malloc_arena_thread_freeres 3577 00052670 t __malloc_assert 3578 00055044 t malloc_check 3579 00055988 t __malloc_check_init 3580 00052ca4 t malloc_consolidate 3581 0005580c t __malloc_fork_lock_parent 3582 00055900 t __malloc_fork_unlock_child 3583 0005587c t __malloc_fork_unlock_parent 3584 000bc240 T malloc_get_state@GLIBC_2.4 3585 000f0bdc V __malloc_hook 3586 00056e98 t mallochook 3587 00055c14 t malloc_hook_ini ------------ However, the current file system of arm linux is read-only, and certain file read and write permissions have been set. Later, I will try to verify the problem again by modifying LD_LIBRARY_PATH Thanks again for your replys
Debuginfo will help, but I think that there is a more fundamental problem. Can you post the "Program Header" from running "objdump -p" on your test exe? This is what I get on a Centos 7.6 aarch64 machine (Cavium ThunderX2-99xx). $ objdump -p /usr/bin/ls /usr/bin/ls: file format elf64-littleaarch64 Program Header: PHDR off 0x0000000000000040 vaddr 0x0000000000400040 paddr 0x0000000000400040 align 2**3 filesz 0x00000000000001f8 memsz 0x00000000000001f8 flags r-x INTERP off 0x0000000000000238 vaddr 0x0000000000400238 paddr 0x0000000000400238 align 2**0 filesz 0x000000000000001b memsz 0x000000000000001b flags r-- LOAD off 0x0000000000000000 vaddr 0x0000000000400000 paddr 0x0000000000400000 align 2**16 filesz 0x000000000001a51c memsz 0x000000000001a51c flags r-x LOAD off 0x000000000001f340 vaddr 0x000000000042f340 paddr 0x000000000042f340 align 2**16 filesz 0x0000000000001280 memsz 0x0000000000001fc0 flags rw- DYNAMIC off 0x000000000001fd28 vaddr 0x000000000042fd28 paddr 0x000000000042fd28 align 2**3 filesz 0x0000000000000210 memsz 0x0000000000000210 flags rw- NOTE off 0x0000000000000254 vaddr 0x0000000000400254 paddr 0x0000000000400254 align 2**2 filesz 0x0000000000000044 memsz 0x0000000000000044 flags r-- EH_FRAME off 0x0000000000017388 vaddr 0x0000000000417388 paddr 0x0000000000417388 align 2**2 filesz 0x00000000000007b4 memsz 0x00000000000007b4 flags r-- STACK off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**4 filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw- RELRO off 0x000000000001f340 vaddr 0x000000000042f340 paddr 0x000000000042f340 align 2**0 filesz 0x0000000000000cc0 memsz 0x0000000000000cc0 flags r--