Menu
▾
▴
valgrind-users
|
From: Vignesh <mv...@ya...> - 2014-05-24 11:21:28
|
Hi, I am having troubles finding memory leaks and array over shoots with valgrind on android. I have a binary that intentionally leaks few bytes. When I run the binary in valgrind environment on an android phone (adb shell), I see valgrind reporting no errors. Please help me understand if I am missing any. I compiled valgrind that came with android release under external directory (git clone https://android.googlesource.com/platform/external/valgrind) My program: -------------- #include <stdio.h> #include <unistd.h> #include <stdlib.h> int main(int argc, char** argv) { int i = 0; char *leak = (char *) malloc(10); char *noleak = (char *)malloc(20); free(noleak); noleak = NULL; return 0; } Name of the executable: sample Output from valgrind: ------------------------ @android:/system/bin # ./valgrind --leak-check=full --tool=memcheck -v sample ==268== Memcheck, a memory error detector ==268== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==268== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==268== Command: sample ==268== --268-- Valgrind options: --268-- --leak-check=full --268-- --tool=memcheck --268-- -v --268-- Contents of /proc/version: --268-- Linux version 3.4.42-eng-gcd82698-00002-g6497f5b (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Wed May 21 17:30:16 IST 2014 --268-- Arch and hwcaps: ARM, ARMv7-vfp-neon --268-- Page sizes: currently 4096, max supported 4096 --268-- Valgrind library directory: /system/lib/valgrind --268-- Reading syms from /system/bin/sample --268-- Considering /system/bin/sample .. --268-- .. CRC mismatch (computed 918c9dfe wanted cde23cf7) --268-- object doesn't have a symbol table --268-- object doesn't have a dynamic symbol table --268-- Reading syms from /system/lib/valgrind/memcheck-arm-linux --268-- Considering /system/lib/valgrind/memcheck-arm-linux .. --268-- .. CRC mismatch (computed 9317450f wanted 4a9e0d91) --268-- object doesn't have a symbol table --268-- object doesn't have a dynamic symbol table --268-- Scheduler: using generic scheduler lock implementation. --268-- Reading suppressions file: /system/lib/valgrind/default.supp ==268== ==268== HEAP SUMMARY: ==268== in use at exit: 0 bytes in 0 blocks ==268== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==268== ==268== All heap blocks were freed -- no leaks are possible ==268== ==268== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==268== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Please help. Regards, Vignesh |
|
From: Philippe W. <phi...@sk...> - 2014-05-24 17:54:37
|
On Sat, 2014-05-24 at 12:21 +0100, Vignesh wrote: > > ==268== HEAP SUMMARY: > ==268== in use at exit: 0 bytes in 0 blocks > ==268== total heap usage: 0 allocs, 0 frees, 0 bytes allocated This seems to indicate that malloc interception is not working. Try to run with -v -v -v -d -d -d -trace-redir=yes and look in the trace to see what is going wrong. Note that your application cannot be statically linked, otherwise redir of malloc et al does not work. (the dynamic linker must be invoked). The malloc library itself can be statically linked but you need to use --soname-synonyms=somalloc=NONE arg then. Philippe |
|
From: Vignesh <mv...@ya...> - 2014-05-26 09:53:23
|
Thank you. My executable was a statically linked one. Will change it to a dynamic executable and hope to have no issues. -Vignesh On Saturday, 24 May 2014, 23:24, Philippe Waroquiers <phi...@sk...> wrote: On Sat, 2014-05-24 at 12:21 +0100, Vignesh wrote: > > ==268== HEAP SUMMARY: > ==268== in use at exit: 0 bytes in 0 blocks > ==268== total heap usage: 0 allocs, 0 frees, 0 bytes allocated This seems to indicate that malloc interception is not working. Try to run with -v -v -v -d -d -d -trace-redir=yes and look in the trace to see what is going wrong. Note that your application cannot be statically linked, otherwise redir of malloc et al does not work. (the dynamic linker must be invoked). The malloc library itself can be statically linked but you need to use --soname-synonyms=somalloc=NONE arg then. Philippe |
|
From: Marc S. <mar...@gm...> - 2014-05-26 10:02:10
|
Keep us updated pls El 26/05/2014 11:59, "Vignesh" <mv...@ya...> escribió: > Thank you. My executable was a statically linked one. > > Will change it to a dynamic executable and hope to have no issues. > > -Vignesh > > > On Saturday, 24 May 2014, 23:24, Philippe Waroquiers < > phi...@sk...> wrote: > > > On Sat, 2014-05-24 at 12:21 +0100, Vignesh wrote: > > > > > > ==268== HEAP SUMMARY: > > ==268== in use at exit: 0 bytes in 0 blocks > > ==268== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > > This seems to indicate that malloc interception is not working. > > Try to run with -v -v -v -d -d -d -trace-redir=yes > and look in the trace to see what is going wrong. > > Note that your application cannot be statically linked, > otherwise redir of malloc et al does not work. > (the dynamic linker must be invoked). > The malloc library itself can be statically linked but > you need to use --soname-synonyms=somalloc=NONE > arg then. > > Philippe > > > > > > > > > ------------------------------------------------------------------------------ > The best possible search technologies are now affordable for all companies. > Download your FREE open source Enterprise Search Engine today! > Our experts will assist you in its installation for $59/mo, no commitment. > Test it for FREE on our Cloud platform anytime! > > http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > |
|
From: Vignesh <mv...@ya...> - 2014-05-27 02:09:12
|
Hi, I am still facing troubles getting a valgrind report on an android phone (armv7-a-neon) after changing my executable to be a dynamically loaded executable. I am not very sure, if I understand the output of the following. ...... ......--16527:1:main Starting the address space manager--16527:2:aspacem sp_at_startup = 0x00be9419a0 (supplied) --16527:2:aspacem minAddr = 0x0004000000 (computed) --16527:2:aspacem maxAddr = 0x00be940fff (computed) --16527:2:aspacem cStart = 0x0004000000 (computed) --16527:2:aspacem vStart = 0x00614a1000 (computed) --16527:2:aspacem suggested_clstack_top = 0x00bd941fff (computed) --16527:2:aspacem <<< SHOW_SEGMENTS: Initial layout (5 segments, 0 segnames) --16527:2:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --16527:2:aspacem 1: 0004000000-00614a0fff 1492m --16527:2:aspacem 2: RSVN 00614a1000-00614a1fff 4096 ----- SmFixed --16527:2:aspacem 3: 00614a2000-00be940fff 1492m --16527:2:aspacem 4: RSVN 00be941000-00ffffffff 1046m ----- SmFixed --16527:2:aspacem >>> ...... --16527-- -d --16527-- --leak-check=yes --16527-- Contents of /proc/version: --16527-- Linux version 3.4.0-eng-g8b0aff7-00013-g2cb89e3 (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Tue Apr 1 17:30:08 IST 2014 --16527-- Arch and hwcaps: ARM, ARMv7-vfp-neon --16527-- Page sizes: currently 4096, max supported 4096 --16527-- Valgrind library directory: /system/lib/valgrind --16527:1:main ...finished the preamble --16527:1:main Initialise the tool part 2 (post_clo_init) --16527:1:main Initialise TT/TC --16527-- TT/TC: VG_(init_tt_tc) (startup of code management) --16527-- TT/TC: cache: 8 sectors of 27597024 bytes each = 220776192 total --16527-- TT/TC: table: 524168 total entries, max occupancy 340704 (65%) --16527:2:transtab cache: 8 sectors of 27597024 bytes each = 220776192 total --16527:2:transtab table: 524168 total entries, max occupancy 340704 (65%) ... ... --16527-- TT/TC: initialise sector 0 --16527-- Reading syms from /system/lib/valgrind/vgpreload_core-arm-linux.so --16527-- svma 0x0000000274, avma 0x0004816274 --16527-- Reading syms from /system/lib/libc.so --16527-- svma 0x000000d1a0, avma 0x00048251a0 --16527-- Considering /system/lib/libc.so .. --16527-- .. CRC mismatch (computed aedb52cb wanted eadc3e5a) --16527-- object doesn't have a symbol table --16527-- Reading syms from /system/lib/libstdc++.so --16527-- svma 0x0000000828, avma 0x0004873828 --16527-- Considering /system/lib/libstdc++.so .. --16527-- .. CRC mismatch (computed 7fca0904 wanted e3efd32e) --16527-- object doesn't have a symbol table --16527-- Reading syms from /system/lib/libm.so --16527-- svma 0x0000002940, avma 0x0004878940 --16527-- Considering /system/lib/libm.so .. --16527-- .. CRC mismatch (computed 5c966341 wanted 751310f2) --16527-- object doesn't have a symbol table --16527-- Reading syms from /system/lib/valgrind/vgpreload_memcheck-arm-linux.so --16527-- svma 0x00000023d4, avma 0x00048933d4 --16527:2:transtab discard_translations(0x4873919, 1) req by redir_new_DebugInfo(from_addr) --16527:2:transtab FAST, ec = 231 --16527:2:transtab discard_translations(0x489946c, 1) req by redir_new_DebugInfo(to_addr) --16527:2:transtab FAST, ec = 50 ==16527== Adding active redirection: --16527:1:mallocfr newSuperblock at 0x642AF000 (pszB 65520) owner VALGRIND/demangle --16527:1:mallocfr deferred_reclaimSuperblock at 0x642AF000 (pszB 65520) (prev 0x0) owner VALGRIND/demangle ...... Complete log available at https://docs.google.com/document/d/1hJFGlDeK9Xyujoa6TaOmOdAVNYH4heApyOZY5C3xxqM/edit Please help. What does --soname-synonyms=somalloc=NONE do? On Monday, 26 May 2014, 15:32, Marc Sampé <mar...@gm...> wrote: Keep us updated pls El 26/05/2014 11:59, "Vignesh" <mv...@ya...> escribió: Thank you. My executable was a statically linked one. > > >Will change it to a dynamic executable and hope to have no issues. > > >-Vignesh > > > >On Saturday, 24 May 2014, 23:24, Philippe Waroquiers <phi...@sk...> wrote: > > > >On Sat, 2014-05-24 at 12:21 +0100, Vignesh wrote: > > >> >> ==268== HEAP SUMMARY: >> ==268== in use at exit: 0 bytes in 0 blocks >> ==268== total heap usage: 0 allocs, 0 frees, 0 bytes allocated >This seems to indicate that malloc interception is not working. > >Try to run with -v -v -v -d -d -d -trace-redir=yes >and look in the trace to see what is going wrong. > >Note that your application cannot be statically linked, >otherwise redir of malloc et al does not work. >(the dynamic linker must be invoked). >The malloc library itself can be statically linked but >you need to use --soname-synonyms=somalloc=NONE >arg then. > >Philippe > > > > > > > >------------------------------------------------------------------------------ >The best possible search technologies are now affordable for all companies. >Download your FREE open source Enterprise Search Engine today! >Our experts will assist you in its installation for $59/mo, no commitment. >Test it for FREE on our Cloud platform anytime! >http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk >_______________________________________________ >Valgrind-users mailing list >Val...@li... >https://lists.sourceforge.net/lists/listinfo/valgrind-users > > |
|
From: John R. <jr...@Bi...> - 2014-05-27 13:30:02
|
> --16527-- Considering /system/lib/libc.so ..
> --16527-- .. CRC mismatch (computed aedb52cb wanted eadc3e5a)
> --16527-- object doesn't have a symbol table
The checksums mismatch, so memcheck ignores the symbols [if there are any.]
Therefore 'malloc' and 'free' cannot be found.
Most often this is a clue that the software on the target machine
is not installed properly. Run "strace -f -e trace=file valgrind ..."
and see exactly which files memcheck wants. Look at all files
that are reported by strace whose names contain the substring "libc",
and determine what kind of symbol tables they contain: SHT_SYMTAB,
DT_SYMTAB (with DT_HASH or DT_GNU_HASH). Figure out why the
CRC mismatches. Check version numbers, date-last-modified ("ls -l"), etc.
Compare output of "readelf --all <filename>" for all candidates.
Install the correct file(s) so that the message
"CRC mismatch" no longer appears.
|
|
From: Vignesh <mv...@ya...> - 2014-06-02 14:05:49
|
Thank you for your clues.
Few dynamically loaded libraries were statically linked to few other libraries. After converting them to dynamic libraries, I am closer to detect memory problems. Also, I had to turn on -g and avoid stripping the executable to get an accurate detection
However, this still dazzles me:
I still get this warning while running valgrind:
--8925-- Considering /system/lib/libc.so ..
--8925-- .. CRC mismatch (computed aedb52cb wanted eadc3e5a)
--8925-- object doesn't have a symbol table
When I compute crc for /system/lib/libc.so externally, I get aedb52cb and the system under test doesn't contain libc anywhere else.. Where else is the executable picking libc from? Output of strace relevant to libc given below
open("/vendor/lib/libc.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/system/lib/libc.so", O_RDONLY) = 3
open("/vendor/lib/libc.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/system/lib/libc.so", O_RDONLY) = 3
readlink("/proc/self/fd/3", "/system/lib/libc.so", 4096) = 19
stat64("/system/lib/libc.so", {st_mode=S_IFREG|0666, st_size=310652, ...}) = 0
readlink("/proc/self/fd/3", "/system/lib/libc.so", 4096) = 19
stat64("/system/lib/libc.so", {st_mode=S_IFREG|0666, st_size=310652, ...}) = 0
readlink("/proc/self/fd/3", "/system/lib/libc.so", 4096) = 19
stat64("/system/lib/libc.so", {st_mode=S_IFREG|0666, st_size=310652, ...}) = 0
--9086-- Reading syms from /system/lib/libc.so
open("/system/lib/libc.so", O_RDONLY) = 4
readlink("/proc/self/fd/4", "/system/lib/libc.so", 4096) = 19
open("/system/lib/libc.so", O_RDONLY) = 4
--9086-- Considering /system/lib/libc.so ..
readlink("/proc/self/fd/4", "/system/lib/libc.so", 4096) = 19
open("/system/lib/.debug/libc.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/system/lib/libc.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/data/local/symbols/system/lib/libc.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/sdcard/symbols/system/lib/libc.so", O_RDONLY) = -1 ENOENT (No such file or directory)
--9086:1:aspacem ( 4) /system/lib/libc.so
--9086-- Caught __NR_exit; running __libc_freeres()
Thank you,
Vignesh
On Tuesday, 27 May 2014, 19:01, John Reiser <jr...@Bi...> wrote:
> --16527-- Considering /system/lib/libc.so ..
> --16527-- .. CRC mismatch (computed aedb52cb wanted eadc3e5a)
> --16527-- object doesn't have a symbol table
The checksums mismatch, so memcheck ignores the symbols [if there are any.]
Therefore 'malloc' and 'free' cannot be found.
Most often this is a clue that the software on the target machine
is not installed properly. Run "strace -f -e trace=file valgrind ..."
and see exactly which files memcheck wants. Look at all files
that are reported by strace whose names contain the substring "libc",
and determine what kind of symbol tables they contain: SHT_SYMTAB,
DT_SYMTAB (with DT_HASH or DT_GNU_HASH). Figure out why the
CRC mismatches. Check version numbers, date-last-modified ("ls -l"), etc.
Compare output of "readelf --all <filename>" for all candidates.
Install the correct file(s) so that the message
"CRC mismatch" no longer appears.
------------------------------------------------------------------------------
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Tom H. <to...@co...> - 2014-06-02 14:41:21
|
On 02/06/14 15:05, Vignesh wrote: > However, this still dazzles me: > > I still get this warning while running valgrind: > --8925-- Considering /system/lib/libc.so .. > --8925-- .. CRC mismatch (computed aedb52cb wanted eadc3e5a) > --8925-- object doesn't have a symbol table > > When I compute crc for /system/lib/libc.so externally, I get aedb52cb > and the system under test doesn't contain libc anywhere else.. Where > else is the executable picking libc from? Output of strace relevant to > libc given below It's not the CRC of libc.so you want, it's the CRC of the debug file. So your libc.so apparently has a .gnu_debuglink section in it which says that there should be a debug image with a CRC of eadc3e5a. The slightly odd thing is that your strace suggests it isn't finding a debug image, so I'm not sure why it is calcing the CRC of the main file instead. None the less, if you have built with a separate debug file then you need to install it so valgrind can find it. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: John R. <jr...@Bi...> - 2014-06-02 14:46:20
|
> Few dynamically loaded libraries were statically linked to few other libraries. After converting them to dynamic libraries, I am closer to detect memory problems. Also, I had to turn on -g and avoid stripping the executable to get an accurate detection
>
> However, this still dazzles me:
>
> I still get this warning while running valgrind:
> --8925-- Considering /system/lib/libc.so ..
> --8925-- .. CRC mismatch (computed aedb52cb wanted eadc3e5a)
> --8925-- object doesn't have a symbol table
>
> When I compute crc for /system/lib/libc.so externally, I get aedb52cb and the system under test doesn't contain libc anywhere else.. Where else is the executable picking libc from? Output of strace relevant to libc given below
I don't know exactly. grep'ping the valgrind source code for "CRC mismatch"
shows coregrind/m_debuginfo/readelf.c function open_debug_file() which is
called from find_debug_file() which is called from "Bool ML_(read_elf_debug_info)".
read_elf_debug_info() gets the "wanted" crc:
/* Extract the CRC from the debuglink section */
UInt crc = ML_(img_get_UInt)(debuglink_escn.img,
debuglink_escn.ioff + crc_offset);
So run memcheck under a debugger, put a breakpoint there, look at the
traceback, and determine which debuglink section is being examined.
One common problem is "crosslinking": building the executable main program
on a different machine, especially one with a different hardware architecture,
such as building an ARM executable using a x86* development environment.
The two libc.so must match in order that valgrind sees the right symbols,
but it is easy for the target machine and the build machine
to get out-of-sync: one gets updated but not the other.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X