localhost:/system/bin # ./valgrind -v --undef-value-errors=no ./test64 MallocInitImpl enter handle:0xd0a1699ce22c0e09 ==8142== Memcheck, a memory error detector ==8142== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==8142== Using Valgrind-3.14.0-353a3587bb-20181007X and LibVEX; rerun with -h for copyright info ==8142== Command: ./test64 ==8142== --8142-- Valgrind options: --8142-- -v --8142-- --undef-value-errors=no --8142-- Contents of /proc/version: --8142-- Linux version 4.4.7+ (root@baixin-HP-Compaq-8200-Elite-MT-PC) (gcc version 4.9.3 20151223 (prerelease) (SDK V100R005C00SPC030B080) ) #1 SMP PREEMPT Fri Sep 9 14:57:05 CST 2016 --8142-- --8142-- Arch and hwcaps: ARM64, LittleEndian, baseline --8142-- Page sizes: currently 4096, max supported 65536 --8142-- Valgrind library directory: /system/lib64/valgrind --8142-- Reading syms from /system_Q_EA3/bin/test64 --8142-- Reading syms from /system_Q_EA3/bin/linker64 --8142-- Reading syms from /system_Q_EA3/lib64/valgrind/memcheck-arm64-linux --8142-- object doesn't have a dynamic symbol table --8142-- Scheduler: using generic scheduler lock implementation. --8142-- Reading suppressions file: /system/lib64/valgrind/default.supp --8142-- Reading syms from /system_Q_EA3/lib64/libc_xom.so --8142-- Reading syms from /system_Q_EA3/lib64/libm.so --8142-- Reading syms from /system_Q_EA3/lib64/valgrind/vgpreload_core-arm64-linux.so --8142-- warning: DiCfSI 0x5a5f000 .. 0x5a5f00b outside mapped rx segments (vgpreload_core-arm64-linux.so) --8142-- warning: DiCfSI 0x5a5f00c .. 0x5a5f00f outside mapped rx segments (vgpreload_core-arm64-linux.so) --8142-- warning: DiCfSI 0x5a5f010 .. 0x5a5f013 outside mapped rx segments (vgpreload_core-arm64-linux.so) --8142-- warning: DiCfSI 0x5a5f014 .. 0x5a5f017 outside mapped rx segments (vgpreload_core-arm64-linux.so) --8142-- warning: DiCfSI 0x5a5f018 .. 0x5a5f073 outside mapped rx segments (vgpreload_core-arm64-linux.so) --8142-- warning: DiCfSI 0x5a5f074 .. 0x5a5f093 outside mapped rx segments (vgpreload_core-arm64-linux.so) --8142-- warning: DiCfSI 0x5a5f094 .. 0x5a5f117 outside mapped rx segments (vgpreload_core-arm64-linux.so) --8142-- Reading syms from /system_Q_EA3/lib64/libdl.so --8142-- warning: DiCfSI 0x5a9a000 .. 0x5a9a007 outside mapped rx segments (libdl.so) --8142-- warning: DiCfSI 0x5a9a008 .. 0x5a9a013 outside mapped rx segments (libdl.so) --8142-- warning: DiCfSI 0x5a9a014 .. 0x5a9a01b outside mapped rx segments (libdl.so) --8142-- Reading syms from /system_Q_EA3/lib64/libc++.so --8142-- Reading syms from /system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so ==8142== Preferring higher priority redirection: --8142-- old: 0x05b58180 (memcpy ) R-> (2018.0) 0x06055a14 memcpy --8142-- new: 0x05b58180 (memcpy ) R-> (2018.1) 0x06057454 memmove linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_core-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags) WARNING: linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_core-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags) linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags) WARNING: linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags) --8142-- REDIR: 0x5b58240 (libc.so:memset) redirected to 0x6057324 (memset) --8142-- REDIR: 0x5b58180 (libc.so:memcpy) redirected to 0x6057454 (memmove) --8142-- REDIR: 0x5b1a32c (libc.so:malloc) redirected to 0x6059148 (malloc) --8142-- REDIR: 0x5b58860 (libc.so:strlen) redirected to 0x60545a4 (strlen) --8142-- REDIR: 0x5b58730 (libc.so:strcpy) redirected to 0x605464c (strcpy) --8142-- REDIR: 0x5b57e00 (libc.so:memchr) redirected to 0x605544c (memchr) MallocInitImpl enter --8142-- REDIR: 0x5b1a2bc (libc.so:free) redirected to 0x605ab48 (free) --8142-- Discarding syms at 0x6054000-0x605d824 in /system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so (have_dinfo 1) ---------------------------------whether these text show why malloc trace is failed, valgrind unload the vgpreload_memcheck-arm64-linux.so , so no memory leak check. --8142-- Reading syms from /system_Q_EA3/lib64/liblog.so handle:0x67b0f9a77f30e9a7 p=0x6813000 p[2049]=5 malloc=0x5b1a32c ==8142== ==8142== HEAP SUMMARY: ==8142== in use at exit: 1,072 bytes in 2 blocks ==8142== total heap usage: 2 allocs, 0 frees, 1,072 bytes allocated ==8142== ==8142== Searching for pointers to 2 not-freed blocks ==8142== Checked 11,189,112 bytes ==8142== ==8142== LEAK SUMMARY: ==8142== definitely lost: 0 bytes in 0 blocks ==8142== indirectly lost: 0 bytes in 0 blocks ==8142== possibly lost: 0 bytes in 0 blocks ==8142== still reachable: 1,072 bytes in 2 blocks ==8142== suppressed: 0 bytes in 0 blocks ==8142== Rerun with --leak-check=full to see details of leaked memory ==8142== ==8142== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==8142== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
-----邮件原件----- 发件人: Wuweijia [mailto:wuwei...@huawei.com] 发送时间: 2019年4月24日 10:56 收件人: John Reiser <jrei...@bitwagon.com>; valgrind-users@lists.sourceforge.net 抄送: Fanbohao <fanbo...@huawei.com> 主题: [Valgrind-users] 答复: Some question about linker dlopen with valgrind Is there any ways to make valgrind to support init_array to dlopen shared object; I think linker can make the right jump to the malloc function without valgirind, so the source is right; I want some ways to trace the valgirnd why redir module to malloc is failue; -----邮件原件----- 发件人: John Reiser [mailto:jrei...@bitwagon.com] 发送时间: 2019年4月23日 23:19 收件人: valgrind-users@lists.sourceforge.net 主题: Re: [Valgrind-users] Some question about linker dlopen with valgrind >> On the Android OS, there is a question about the linker program >> with vaglrind memcheck. Which version of Android? >> >> The 1^st experiment, the libc module *do*call the dlopen >> function to load some shared object, before the linker call the >> pre_init functions ( before transfer the cpu control to the main ), >> and then the valgrind *can not*trace malloc leak; >> >> The second experiment, the libc module *do not*call the >> dlopen function to load some shared object, before the linker call >> the pre_init functions ( before transfer the cpu control to the main >> ), and then the valgrind *can* trace malloc leak; >> >> I want to know why , and how to make valgrind can trace memory >> leak, while the libc module call the dlopen function to load some so, >> before the linker call the pre-init functions. According to https://docs.oracle.com/cd/E19683-01/816-1386/6m7qcobks/index.html the order of execution is: 1. linker resolves and fetches all DT_NEEDED modules (shared libraries), and performs all relocations for the entire process image 2. linker calls DT_PREINIT_ARRAY functions of the main program, in order (only a main program may have DT_PREINIT_ARRAY; a shared library MUST NOT) 3. in dependency order (topological bottom-up) of all loaded modules (main program and shared libraries): linker calls DT_INIT and then DT_INIT_ARRAY (in order) for the module 4. linker transfers control to the ElfXX_Ehdr.e_entry address of the main program It is undefined what happens if a DT_PREINIT_ARRAY, DT_INIT_ARRAY, or DT_INIT function calls dlopen, particularly if the newly-loaded module depends on any other modules, whether or not those modules have been loaded already. (The dependent module might not be initialized yet.) _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
