I am trying to build valgrind to help debug a native Android
application. The host I am compiling on is a Mac running Mac OS
10.8.3. The target is an internal prototype x86 tablet running
Android 4.0.4. I am using Android NDK r8e.
I started with the release version of Valgrind 3.8.1. When I ran into
the premature exit described at the end of this note, I switched to
the svn version.
I followed the instructions in README.android, setting HWKIND to
generic, and making to following changes to get valgrind to build:
1) In the environment variable definitions for the build tools,
substituted "darwin-x86_64" for "linux-x86" in the path to each of
the tools.
2) Added:
export
RANLIB=$NDKROOT/toolchains/x86-4.4.3/prebuilt/linux-x86/bin/i686-android-li
nux-ranlib
to get the right ranlib executable
3) The target cpu/kernel detection logic assumes it is building for
the host CPU. The --target and --host options cover most of the
issues, but the configure script tries to run "uname -r" to get the
kernel version.
The logic in configure.in that matches kernel versions treats 2.6.*
and 3.0.* the same way, so if you are building on a relatively
recent Linux system it will probably work fine. Mac OS is
returning an OS version of 12.3.0, which is unrelated to the
Android kernel version.
I hardcoded configure.in to use version "3.0.8" to match my actual
device, though maybe calling 'adb shell uname -r' would make more
sense for android targets.
4) The types uint32_t and uint64_t are referenced in the system elf.h,
and not defined by default on my system, so I added "#include
<stdint.h>" prior to each "#include <elf.h>"
(coregrind/m_main.c:2987, coregrind/m_coredump/coredump-elf.c:57,
coregrind/m_debuginfo/readelf.c:57,
coregrind/m_initimg/initimg-linux.c:60, coregrind/m_ume/elf.c:53,
coregrind/launcher-linux.c:47)
When I run "/data/local/Inst/bin/valgrind ls", ls runs without any
errors, and I get the expected output:
==32681== Memcheck, a memory error detector
==32681== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==32681== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright
info
==32681== Command: ls
==32681==
[... ls output deleted ... ]
==32681==
==32681== HEAP SUMMARY:
==32681== in use at exit: 1,024 bytes in 1 blocks
==32681== total heap usage: 41 allocs, 40 frees, 5,967 bytes allocated
==32681==
==32681== LEAK SUMMARY:
==32681== definitely lost: 0 bytes in 0 blocks
==32681== indirectly lost: 0 bytes in 0 blocks
==32681== possibly lost: 0 bytes in 0 blocks
==32681== still reachable: 1,024 bytes in 1 blocks
==32681== suppressed: 0 bytes in 0 blocks
==32681== Rerun with --leak-check=full to see details of leaked memory
==32681==
==32681== For counts of detected and suppressed errors, rerun with: -v
==32681== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
I then added a wrapper, as described by jseward's blog post
(http://blog.mozilla.org/jseward/2011/09/27/valgrind-on-android-current-sta
tus/),
and included the --smc-check=all in the VGPARAMS, because it sounded
like it would be required for an x86 build. The whole
/data/local/start_valgrind_myprog file looks like this:
#!/system/bin/sh
VGPARAMS='--error-limit=no --smc-check=all'
export TMPDIR=/data/data/com.intel.central
exec /data/local/Inst/bin/valgrind $VGPARAMS $*
When I start my application with:
am start -a android.intent.action.MAIN -n
com.intel.central/.MainActivity
I see the following in logcat:
I//data/local/start_valgrind_myprog(32640): ==32641== Using
Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
I//data/local/start_valgrind_myprog(32640): ==32641== Command:
/system/bin/app_process /system/bin --application
--nice-name=com.intel.central com.andr\
oid.internal.os.WrapperInit 32 17 android.app.ActivityThread
I//data/local/start_valgrind_myprog(32640): ==32641==
I//data/local/start_valgrind_myprog(32640): valgrind:
m_debuginfo/readelf.c:577 (get_elf_symbol_info): Assertion 'in_rx' failed.
I//data/local/start_valgrind_myprog(32640): ==32641== at 0x38033455:
report_and_quit (m_libcassert.c:260)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x38033851:
vgPlain_assert_fail (m_libcassert.c:340)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x3806D80E:
read_elf_symtab__normal (readelf.c:577)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x380705F3:
vgModuleLocal_read_elf_debug_info (readelf.c:2655)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x3806A449:
vgPlain_di_notify_mmap (debuginfo.c:629)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x38097510:
vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2087)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x380C9A0B:
vgSysWrap_x86_linux_sys_mmap2_before (syswrap-x86-linux.c:1247)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x3808C830:
vgPlain_client_syscall (syswrap-main.c:1522)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x38089C12:
vgPlain_scheduler (scheduler.c:1066)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x380C1188:
run_a_thread_NORETURN (syswrap-linux.c:103)
I//data/local/start_valgrind_myprog(32640): sched status:
I//data/local/start_valgrind_myprog(32640): running_tid=1
I//data/local/start_valgrind_myprog(32640): Thread 1: status =
VgTs_Runnable
I//data/local/start_valgrind_myprog(32640): ==32641== at 0xB000F261:
__dl___mmap2 (in /system/bin/linker)
I//data/local/start_valgrind_myprog(32640): Note: see also the FAQ in the
source distribution.
I//data/local/start_valgrind_myprog(32640): It contains workarounds to
several common problems.
I//data/local/start_valgrind_myprog(32640): In particular, if Valgrind
aborted or crashed after
I//data/local/start_valgrind_myprog(32640): identifying problems in your
program, there's a good chance
I//data/local/start_valgrind_myprog(32640): that fixing those problems
will prevent Valgrind aborting or
I//data/local/start_valgrind_myprog(32640): crashing, especially if it
happened in m_mallocfree.c.
I//data/local/start_valgrind_myprog(32640): If that doesn't help, please
report this bug to: www.valgrind.org
I//data/local/start_valgrind_myprog(32640): In the bug report, send all
the above text, the valgrind
I//data/local/start_valgrind_myprog(32640): version, and what OS and
version you are using. Thanks.
The wrapper script appears to be launching the application, but it
looks like valgrind is exiting immediately with an assertion failure.
Any ideas what could be going wrong or how to fix it?
Thanks,
Bill.
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
