|
From: Wuweijia <wuw...@hu...> - 2019-04-08 03:51:50
|
Elf file type is DYN (Shared object file) Entry point 0x47000 There are 9 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x0001f8 0x0001f8 R 0x8 LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x0469bc 0x0469bc R 0x1000 LOAD 0x047000 0x0000000000047000 0x0000000000047000 0x10ee20 0x10ee20 E 0x1000 LOAD 0x156000 0x0000000000156000 0x0000000000156000 0x00a598 0x221fa8 RW 0x1000 DYNAMIC 0x15ee20 0x000000000015ee20 0x000000000015ee20 0x0001c0 0x0001c0 RW 0x8 GNU_RELRO 0x15a000 0x000000000015a000 0x000000000015a000 0x006598 0x007000 R 0x1 GNU_EH_FRAME 0x02a2a4 0x000000000002a2a4 0x000000000002a2a4 0x005ddc 0x005ddc R 0x4 GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0 NOTE 0x000238 0x0000000000000238 0x0000000000000238 0x000038 0x000038 R 0x4 Valgrind can not find memory leak with malloc; I think maybe there is something different with GNU LD command; because there is two segment new; Please focus on the text in blue; |
|
From: John R. <jr...@bi...> - 2019-04-08 04:24:15
|
> Elf file type is DYN (Shared object file)
> Entry point 0x47000
> There are 9 program headers, starting at offset 64
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x0001f8 0x0001f8 R 0x8
> LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x0469bc 0x0469bc R 0x1000
> LOAD 0x047000 0x0000000000047000 0x0000000000047000 0x10ee20 0x10ee20 E 0x1000
> LOAD 0x156000 0x0000000000156000 0x0000000000156000 0x00a598 0x221fa8 RW 0x1000
> DYNAMIC 0x15ee20 0x000000000015ee20 0x000000000015ee20 0x0001c0 0x0001c0 RW 0x8
> GNU_RELRO 0x15a000 0x000000000015a000 0x000000000015a000 0x006598 0x007000 R 0x1
> GNU_EH_FRAME 0x02a2a4 0x000000000002a2a4 0x000000000002a2a4 0x005ddc 0x005ddc R 0x4
> GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0
> NOTE 0x000238 0x0000000000000238 0x0000000000000238 0x000038 0x000038 R 0x4
> Valgrind can not find memory leak with malloc;
Which version of valgrind? (Run "valgrind --version".)
Please post the valgrind output just before and just after
the place where the report of memory leaks should appear.
Please re-run using "valgrind -v ..." and show the output
from the very beginning until the last REDIR message, such as:
--15470-- REDIR: 0x4ebf390 (libc.so.6:malloc) redirected to 0x4c2edc9 (malloc)
--15470-- REDIR: 0x4ebf9e0 (libc.so.6:free) redirected to 0x4c2ffca (free)
> I think maybe there is something different with GNU LD command; because there is two segment new;
> Please focus on the text in blue;
The text that was originally posted to [valgrind-users] was all in black. There was no blue.
Please post the output from:
readelf --dynamic <the_program>
ldd <the_program>
|
|
From: Wuweijia <wuw...@hu...> - 2019-04-08 23:54:50
|
localhost:/system/bin # ./valgrind -v --undef-value-errors=no ./test
==30806== Memcheck, a memory error detector
==30806== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==30806== Using Valgrind-3.14.0-353a3587bb-20181007X and LibVEX; rerun with -h for copyright info
==30806== Command: ./test
==30806==
--30806-- Valgrind options:
--30806-- -v
--30806-- --undef-value-errors=no
--30806-- Contents of /proc/version:
--30806-- 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
--30806--
--30806-- Arch and hwcaps: ARM64, LittleEndian, baseline
--30806-- Page sizes: currently 4096, max supported 65536
--30806-- Valgrind library directory: /system/lib64/valgrind
--30806-- Reading syms from /system_Q_EA3/bin/test
--30806-- Reading syms from /system_Q_EA3/bin/linker64
--30806-- Scheduler: using generic scheduler lock implementation.
--30806-- Reading suppressions file: /system/lib64/valgrind/default.supp
--30806-- Reading syms from /system_Q_EA3/lib64/libm.so
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)
new lld p=0x5613000
==30806==
==30806== HEAP SUMMARY:
==30806== in use at exit: 0 bytes in 0 blocks
==30806== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==30806==
==30806== All heap blocks were freed -- no leaks are possible
==30806==
==30806== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==30806== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
ocalhost:/system/bin # readelf -d ../lib64/libc.so
Dynamic section at offset 0x15ee20 contains 28 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [ld-android.so]
0x0000000000000001 (NEEDED) Shared library: [libdl.so]
0x000000000000000e (SONAME) Library soname: [libc.so]
0x000000000000001e (FLAGS) BIND_NOW
0x000000006ffffffb (FLAGS_1) Flags: NOW
0x0000000000000007 (RELA) 0xf188
0x0000000000000008 (RELASZ) 39288 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffff9 (RELACOUNT) 1575
0x0000000000000017 (JMPREL) 0x18b00
0x0000000000000002 (PLTRELSZ) 13776 (bytes)
0x0000000000000003 (PLTGOT) 0x15f390
0x0000000000000014 (PLTREL) RELA
0x0000000000000006 (SYMTAB) 0x270
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000005 (STRTAB) 0xb1c4
0x000000000000000a (STRSZ) 16323 (bytes)
0x000000006ffffef5 (GNU_HASH) 0x8f10
0x0000000000000019 (INIT_ARRAY) 0x15edf8
0x000000000000001b (INIT_ARRAYSZ) 40 (bytes)
0x000000000000001a (FINI_ARRAY) 0x15a000
0x000000000000001c (FINI_ARRAYSZ) 16 (bytes)
0x000000006ffffff0 (VERSYM) 0x8328
0x000000006ffffffc (VERDEF) 0x8de4
0x000000006ffffffd (VERDEFNUM) 9
0x000000006ffffffe (VERNEED) 0x8ee0
0x000000006fffffff (VERNEEDNUM) 1
0x0000000000000000 (NULL) 0x0
The text in blue as below:
> LOAD 0x000000 0x0000000000000000 0x0000000000000000
> 0x0469bc 0x0469bc R 0x1000
> LOAD 0x047000 0x0000000000047000 0x0000000000047000
> 0x10ee20 0x10ee20 E 0x1000
> LOAD 0x156000 0x0000000000156000 0x0000000000156000
> 0x00a598 0x221fa8 RW 0x1000
> DYNAMIC 0x15ee20 0x000000000015ee20 0x000000000015ee20
> 0x0001c0 0x0001c0 RW 0x8
-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...]
发送时间: 2019年4月8日 12:24
收件人: val...@li...
主题: Re: [Valgrind-users] [HELP] Android use LD to link the program but the valgrind can not report malloc leak;
> Elf file type is DYN (Shared object file) Entry point 0x47000 There
> are 9 program headers, starting at offset 64
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flg Align
> PHDR 0x000040 0x0000000000000040 0x0000000000000040
> 0x0001f8 0x0001f8 R 0x8
> LOAD 0x000000 0x0000000000000000 0x0000000000000000
> 0x0469bc 0x0469bc R 0x1000
> LOAD 0x047000 0x0000000000047000 0x0000000000047000
> 0x10ee20 0x10ee20 E 0x1000
> LOAD 0x156000 0x0000000000156000 0x0000000000156000
> 0x00a598 0x221fa8 RW 0x1000
> DYNAMIC 0x15ee20 0x000000000015ee20 0x000000000015ee20
> 0x0001c0 0x0001c0 RW 0x8
> GNU_RELRO 0x15a000 0x000000000015a000 0x000000000015a000
> 0x006598 0x007000 R 0x1
> GNU_EH_FRAME 0x02a2a4 0x000000000002a2a4 0x000000000002a2a4
> 0x005ddc 0x005ddc R 0x4
> GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000
> 0x000000 0x000000 RW 0
> NOTE 0x000238 0x0000000000000238 0x0000000000000238
> 0x000038 0x000038 R 0x4
> Valgrind can not find memory leak with malloc;
Which version of valgrind? (Run "valgrind --version".)
Please post the valgrind output just before and just after the place where the report of memory leaks should appear.
Please re-run using "valgrind -v ..." and show the output from the very beginning until the last REDIR message, such as:
--15470-- REDIR: 0x4ebf390 (libc.so.6:malloc) redirected to 0x4c2edc9 (malloc)
--15470-- REDIR: 0x4ebf9e0 (libc.so.6:free) redirected to 0x4c2ffca (free)
> I think maybe there is something different with GNU LD command;
> because there is two segment new;
> Please focus on the text in blue;
The text that was originally posted to [valgrind-users] was all in black. There was no blue.
Please post the output from:
readelf --dynamic <the_program>
ldd <the_program>
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: John R. <jr...@bi...> - 2019-04-09 06:00:52
|
On 4/8/19 4:54 PM, Wuweijia wrote: > localhost:/system/bin # ./valgrind -v --undef-value-errors=no ./test > ==30806== Memcheck, a memory error detector > ==30806== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==30806== Using Valgrind-3.14.0-353a3587bb-20181007X and LibVEX; rerun with -h for copyright info > 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) Please visit https://bugs.kde.org/show_bug.cgi?id=406349 and enter the version of Android and/or /system_Q_EA3/bin/linker64 into an Additional Comment. Also please attach the source code of the test program ./test to the valgrind bug report. The Android run-time linker /system_Q_EA3/bin/linker64 does not understand important flags in the DF_FLAGS_1 data item of the PT_DYNAMIC "segment" of /lib64/valgrind/vgpreload_core-arm64-linux.so and other valgrind shared libraries. As a result, memcheck does not re-direct nor intercept calls to malloc() or free(). This cripples memcheck. |