|
From: Wuweijia <wuw...@hu...> - 2019-04-24 03:17:43
|
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:wuw...@hu...]
发送时间: 2019年4月24日 10:56
收件人: John Reiser <jr...@bi...>; val...@li...
抄送: Fanbohao <fan...@hu...>
主题: [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:jr...@bi...]
发送时间: 2019年4月23日 23:19
收件人: val...@li...
主题: 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
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|