| Summary: | Support running Valgrind for Android on ARM | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Jeff Brown <jeffbrown> |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | REPORTED --- | ||
| Severity: | major | CC: | austinenglish, cms8941, cpigat242, david.gilbert, eugeni.stepanov, gitta471, jeffbrown, josef.weidendorfer, jreiser, kenny, lcj.dev, leon.lyn, m.k.edwards, matek09, ratamovic, realbrightster, richard.liu.sh, seka.rao, v82.ranjan, vinay.dce, wanmohdfairuz, WayneShu |
| Priority: | NOR | ||
| Version First Reported In: | 3.6.0 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Set _start symbol alignment and type.
Rename __unused members to __unused1. Support DMB and DSB variants on ARM. Support LDREXD / STREXD on ARM. Ignore register argument used in DSB, DMB and ISB. Support DMB and DSB variants on Thumb. Support ADDW on Thumb. Support SUBW on Thumb. Handle sigaction, sigsuspend, sigprocmask Configure-time temporary directory support Support (T2) SUB{S}.W Rd, SP, #constT Fix jump kind for indirect BLX. Support binder and ashmem ioctls. Fix for LLSC implementation on ~VEX_HWCAPS_ARM_NEON Thumb ldrexd and strexd strace result |
||
|
Description
Jeff Brown
2011-02-10 23:21:55 UTC
Created attachment 57134 [details]
Set _start symbol alignment and type.
The _start entry point needs to be explicitly placed in a .text section, aligned and marked as a function for tools like objdump to work. Otherwise Valgrind tools are not considered valid executables and they fail to run on the first instruction.
This declaration for _start matches the one we use for Bionic on ARM.
Created attachment 57135 [details]
Rename __unused members to __unused1.
BSD-style libc such as Bionic contain compatibility declarations like the following in libc/include/sys/cdefs.h.
#define __unused __attribute__((__unused__))
Unfortunately that conflicts with identifiers called __unused. This is kind of broken but programs shouldn't use double-underscore prefixed identifiers anyways.
Created attachment 57136 [details]
Support DMB and DSB variants on ARM.
Need to support opcodes such as "dmb st" which have different options from the usual "dmb sy" et al.
Created attachment 57137 [details]
Support LDREXD / STREXD on ARM.
Add ldrexd and strexd opcodes.
Created attachment 57138 [details]
Ignore register argument used in DSB, DMB and ISB.
These opcodes compile down to MCR 15, 0, rN, c7, c10, OP. The register argument is irrelevant here. Ignore it.
Some pre-existing code in third-party libraries contains variations of these opcodes that use other registers such as R3 instead of R0 as in the canonical case.
Created attachment 57139 [details]
Support DMB and DSB variants on Thumb.
Need thumb variations like "dmb st" in addition to the usual "dmb sy".
Created attachment 57141 [details]
Support ADDW on Thumb.
Need the ADDW instruction in thumb with an immediate operand.
Created attachment 57142 [details]
Support SUBW on Thumb.
Need SUBW with an immediate operand.
Please note that Kenny Root also deserves credit for several of these patches. Created attachment 57144 [details]
Handle sigaction, sigsuspend, sigprocmask
Move the sigaction and sigsuspend handlers to the syswrap-linux.c file
because they're the same for x86, ppc32, and arm.
Created attachment 57166 [details]
Configure-time temporary directory support
Android has no /tmp directory, so we must be able to change this.
Created attachment 57584 [details]
Support (T2) SUB{S}.W Rd, SP, #constT
Another missing instruction.
Note that most of these patches are not just for Android; several add support for Thumb2 and ARMv7 opcodes that can appear in general Linux binaries. Created attachment 58040 [details]
Fix jump kind for indirect BLX.
Jump kind for BLX rN was incorrectly set to Ijk_Boring. This resulted in most, if not all, indirect functions calls being interpreted as plain jumps.
Valgrind dies on Android for dynamically linked programs, works fine with statically linked programs, https://bugs.kde.org/show_bug.cgi?id=268545 https://bugs.kde.org/show_bug.cgi?id=270709 Memcheck gives false reports with Thumb binaries. As a workaround, build you programs with -marm. What's the status of this patchset now? How well does it work? It works just fine, but there is a nit: some work needs to be done on the build system to support Android toolchain (mostly, for Bionic/GLibC incompatibilities). We have a custom makefile for building Valgrind from inside Android tree, and we plan to publish it on source.android.com soon. We also have a patch to support Android-specific binder and ashmem ioctls. I'll add it to this bug tomorrow if there is interest. Other than that, almost all of these patches are generic ARM bugfixes. Created attachment 59177 [details]
Support binder and ashmem ioctls.
Credit for the ashmem part goes to Jeff Brown.
Binder support in this patch has a known false positive (write_buffer[] points to uninitialised byte(s)). Payload parsing is required to avoid this; I'll update the patch later.
(In reply to comment #14) > Created an attachment (id=58040) [details] > Fix jump kind for indirect BLX. What problem does this solve? (iow, how did you know it was a problem?) (In reply to comment #20) > (In reply to comment #14) > > Created an attachment (id=58040) [details] [details] > > Fix jump kind for indirect BLX. > > What problem does this solve? (iow, how did you know it was a problem?) TSan has a recursive ignore mechanism, where we track procedure calls and returns and ignore everything below some function. This bug made some calls look like plain jumps. This is actually a very common instruction. Every indirect call that can possibly go to another translation unit (or, even, simply every indirect call) is done with indirect BLX. I use this for configuring Valgrind: CC=arm-none-linux-gnueabi-gcc CFLAGS="-pipe -Os -static -mtune=cortex-a9 -march=armv7-a -mabi=aapcs-linux -msoft-float -I/apps/codesourcery/arm-gcc/current/arm-none-linux-gnueabi/libc/usr/include" LDFLAGS="-L/apps/codesourcery/arm-gcc/current/arm-none-linux-gnueabi/libc/usr/lib" ./configure --prefix=/data/psi_omap_builds_users/x0152532/valgrind --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi --build=i686-ubuntu-linux --with-tmpdir=/data/tmp It compiled but when I execute valgrind on target machine (Android on Arm), I got this: /data/test # valgrind ./test-arm valgrind: m_ume.c: can't open interpreter Is there any special library I need to include? Thanks and regards, Fairuz As it shows up, U have used arm-none-linux-gnueabi-gcc for compiling valgrind, and I suppose u have compiled ur test program test-arm with bionic library and tool chain. Then obviously, the a.out format of test-arm is not known to the cross-compiled valgrind tool and hence it is not able to find the right interpreter to run the test-arm program in valgrind's environment. can u give the output of file test-arm and file valgrind Hi, So we need to compile both Valgrind and test program using bionic library? (In reply to comment #24) > Hi, > So we need to compile both Valgrind and test program using bionic library? Exactly, you need to compile both Valgrind and test program using either bionic library gcc OR arm-none-linux-gnueabi-gcc? (In reply to comment #25) > (In reply to comment #24) > > Hi, > > So we need to compile both Valgrind and test program using bionic library? > > Exactly, > you need to compile both Valgrind and test program using either bionic library > gcc OR arm-none-linux-gnueabi-gcc? Thanks, it does make sense.. But for memcheck (I'm not sure about other tools), it will fail to intercept malloc/free calls for statically linked executable. (as referred here http://sourceforge.net/mailarchive/message.php?msg_id=27395113).. So I assume programs compiled using arm-none-linux-gnueabi-gcc can't be used at all here. So that will leave us only to the combination of dynamically linked executable (using bionic library) and statically/dynamically linked Valgrind (using bionic library of course)? What do you think? Thanks. (In reply to comment #26) > (In reply to comment #25) > > (In reply to comment #24) > > > Hi, > > > So we need to compile both Valgrind and test program using bionic library? > > > > Exactly, > > you need to compile both Valgrind and test program using either bionic library > > gcc OR arm-none-linux-gnueabi-gcc? > > Thanks, it does make sense.. But for memcheck (I'm not sure about other tools), > it will fail to intercept malloc/free calls for statically linked executable. > (as referred here > http://sourceforge.net/mailarchive/message.php?msg_id=27395113).. So I assume > programs compiled using arm-none-linux-gnueabi-gcc can't be used at all here. > > So that will leave us only to the combination of dynamically linked executable > (using bionic library) and statically/dynamically linked Valgrind (using bionic > library of course)? What do you think? Thanks. Yes, a dynamic/statically linked valgrind with one C library(gcc OR arm-none-linux-gnueabi-gcc) wud do. Ok, my update until now. - I compile 2 versions of valgrind (patched with all the patch set provided in this page), one with standard libc and one with bionic libc (correct me if I compile it wrong :D) using configure options as below: ** std libc ARCH=arm CC=arm-none-linux-gnueabi-gcc CFLAGS="-DANDROID -static -I/apps/codesourcery/arm-gcc/arm-2010q1-202/arm-none-linux-gnueabi/libc/usr/include" LDFLAGS="-L/apps/codesourcery/arm-gcc/arm-2010q1-202/arm-none-linux-gnueabi/libc/usr/lib" ./configure --prefix=/data/valgrind --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi --build=i686-ubuntu-linux --with-tmpdir=/data/tmp **bionic libc ARCH=arm CC=arm-none-linux-gnueabi-gcc CFLAGS="-static" LDFLAGS="-L/home/x0152532/android/out/target/product/generic/system/lib" ./configure --prefix=/data/valgrind --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi --build=i686-ubuntu-linux --with-tmpdir=/data/tmp - For test program, I output Hello World using printf and allocate+free an int. I compiled it for x86, arm-static and arm-bionic. For arm-bionic I follow instructions here http://android-dls.com/wiki/index.php?title=Compiling_for_Android ..All test program (x86, arm-static and arm-bionic) runs well alone on respective platform (the hello world come out good). Then comes the moment to test them with valgrind. =) --> x86 (dynamically linked, so the result is good) ==17218== total heap usage: 1 allocs, 1 frees, 4 bytes allocated --> arm-static (statically linked with standard libc, as statically linked executable do not work with memcheck, so I'm expecting to get 0 allocs) ==2258== total heap usage: 0 allocs, 0 frees, 0 bytes allocated --> arm-bionic (compiled using agcc -- link provided above) /data # valgrind ./hello-arm-bionic valgrind: mmap(0x0, 2952865436) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. So, is there any additional work I have to do after applying the patches to make it work? Thanks. Regards, Fairuz (In reply to comment #28) > Ok, my update until now. > > - I compile 2 versions of valgrind (patched with all the patch set provided in > this page), one with standard libc and one with bionic libc (correct me if I > compile it wrong :D) using configure options as below: > > ** std libc > ARCH=arm CC=arm-none-linux-gnueabi-gcc CFLAGS="-DANDROID -static > -I/apps/codesourcery/arm-gcc/arm-2010q1-202/arm-none-linux-gnueabi/libc/usr/include" > LDFLAGS="-L/apps/codesourcery/arm-gcc/arm-2010q1-202/arm-none-linux-gnueabi/libc/usr/lib" > ./configure --prefix=/data/valgrind --host=arm-none-linux-gnueabi > --target=arm-none-linux-gnueabi --build=i686-ubuntu-linux > --with-tmpdir=/data/tmp > > **bionic libc > ARCH=arm CC=arm-none-linux-gnueabi-gcc CFLAGS="-static" > LDFLAGS="-L/home/x0152532/android/out/target/product/generic/system/lib" > ./configure --prefix=/data/valgrind --host=arm-none-linux-gnueabi > --target=arm-none-linux-gnueabi --build=i686-ubuntu-linux > --with-tmpdir=/data/tmp > > - For test program, I output Hello World using printf and allocate+free an int. > I compiled it for x86, arm-static and arm-bionic. For arm-bionic I follow > instructions here > http://android-dls.com/wiki/index.php?title=Compiling_for_Android ..All test > program (x86, arm-static and arm-bionic) runs well alone on respective platform > (the hello world come out good). > > Then comes the moment to test them with valgrind. =) > --> x86 (dynamically linked, so the result is good) > ==17218== total heap usage: 1 allocs, 1 frees, 4 bytes allocated > > --> arm-static (statically linked with standard libc, as statically linked > executable do not work with memcheck, so I'm expecting to get 0 allocs) > ==2258== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > > --> arm-bionic (compiled using agcc -- link provided above) > /data # valgrind ./hello-arm-bionic > valgrind: mmap(0x0, 2952865436) failed in UME with error 22 (Invalid argument). > valgrind: this can be caused by executables with very large text, data or bss > segments. > > So, is there any additional work I have to do after applying the patches to > make it work? > > Thanks. > > Regards, > Fairuz You came to sail in the boat, I am sailing in, Here is my bug "Valgrind dies on Android for dynamically linked programs, works fine with statically linked programs, https://bugs.kde.org/show_bug.cgi?id=268545" And in your comment, u gave bionic lib instructions, and CC was arm-none-linux-gnueabi-gcc, r u sure u have used bionic lib, albeit, even compiling with real ndk-5b bionic standalone tool chain yields the same error of UME. load_ELF() must protect against stupid ElfXX_Phdr having .p_memsz==0.
--- coregrind/m_ume/elf.c (revision 11720)
+++ coregrind/m_ume/elf.c (working copy)
@@ -390,7 +390,7 @@
ESZ(Phdr) *iph = &interp->p[j];
ESZ(Addr) end;
- if (iph->p_type != PT_LOAD)
+ if (iph->p_type != PT_LOAD || iph->p_memsz == 0)
continue;
if (!baseaddr_set) {
(In reply to comment #12) > Created an attachment (id=57584) [details] > Support (T2) SUB{S}.W Rd, SP, #constT Isn't this already supported? Look for this comment in guest_arm_toIR.c: /* but allow "sub{s}.w reg, sp, #constT this is (T2) of "SUB (SP minus immediate)" */ (In reply to comment #1) > Created an attachment (id=57134) [details] > Set _start symbol alignment and type. Committed, r11720. (In reply to comment #3) > Created an attachment (id=57136) [details] > Support DMB and DSB variants on ARM. Committed, r2143. (In reply to comment #6) > Created an attachment (id=57139) [details] > Support DMB and DSB variants on Thumb. Committed, r2146. (In reply to comment #14) > Created an attachment (id=58040) [details] > Fix jump kind for indirect BLX. Committed, r2147. (In reply to comment #7) > Need the ADDW instruction in thumb with an immediate operand. (In reply to comment #8) > Need SUBW with an immediate operand. Couldn't these be combined? They are almost identical. See for example the cases for "ADDS Rn, #uimm8" and "SUBS Rn, #uimm8". Also (more importantly) please add some test cases to none/tests/arm/v6intThumb.c for these. > > Support (T2) SUB{S}.W Rd, SP, #constT
>
> Isn't this already supported? Look for this comment in guest_arm_toIR.c:
>
> /* but allow "sub{s}.w reg, sp, #constT
> this is (T2) of "SUB (SP minus immediate)" */
Yes, it seems so. My patch was 3 weeks earlier :)
(In reply to comment #19) > Created an attachment (id=59177) [details] > Support binder and ashmem ioctls. > > Credit for the ashmem part goes to Jeff Brown. > Binder support in this patch has a known false positive (write_buffer[] points > to uninitialised byte(s)). Payload parsing is required to avoid this; I'll > update the patch later. In fact, it's fine as it is. This ioctl is normally used only through single library, and we just fixed it. The Android port of Valgrind is now available here: http://source.android.com/ http://android.git.kernel.org/?p=platform/external/valgrind.git Dear All, I am building valgrind from http://android.git.kernel.org/?p=platform/external/valgrind.git, getting below error. target StaticExecutable: helgrind-arm-linux (out/target/product/generic/obj/SHARED_LIBRARIES/helgrind-arm-linux_intermediates/LINKED/helgrind-arm-linux) prebuilt/linux-x86/toolchain/arm-linux-androideabi-4.4.x/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld: error: out/target/product/generic/obj/STATIC_LIBRARIES/libcoregrind-arm-linux_intermediates/libcoregrind-arm-linux.a(m_main.o): multiple definition of '_start' prebuilt/linux-x86/toolchain/arm-linux-androideabi-4.4.x/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld: out/target/product/generic/obj/lib/crtbegin_static.o: previous definition here prebuilt/linux-x86/toolchain/arm-linux-androideabi-4.4.x/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld: out/target/product/generic/obj/lib/crtbegin_static.o:(.text+0x10): error: undefined reference to '__libc_init' prebuilt/linux-x86/toolchain/arm-linux-androideabi-4.4.x/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld: out/target/product/generic/obj/lib/crtbegin_static.o:(.text+0x14): error: undefined reference to 'main' If you guys know about above error and how to solve it, please let me know. Thanks in advance Vikash. I've had the same problem and solved it by using a more recent "build" project. Look for Build system tweaks for Valgrind (commit bd528a82a24). Thanks a lot Its Working Now. Created attachment 60956 [details]
Fix for LLSC implementation on ~VEX_HWCAPS_ARM_NEON
There is a bug in implementation of "Load Linked and Store Conditional" (host_arm_isel.c).
The symptom is:
"vex: external/valgrind/main/VEX/priv/host_arm_isel.c:128 (lookupIRTemp64): Assertion `env->vregmapHI[tmp] != ((HReg)0xFFFFFFFF)' failed."
The assertion is caused by a call to lookupIRTemp64() which should only be called if (!(arm_hwcaps & VEX_HWCAPS_ARM_NEON)), because otherwise hregHI is not set.
dear all, i build valgrind on android2.3, then i tried this "valgrind ls", 'the 'impossible' happened': # valgrind ls ==3843== Memcheck, a memory error detector ==3843== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==3843== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==3843== Command: ls ==3843== ==3843== Invalid write of size 4 ==3843== at 0xB00065E0: ??? (in /system/bin/linker) ==3843== Address 0xafd4d484 is not stack'd, malloc'd or (recently) free'd ==3843== ==3843== ==3843== ==3843== ==3843== WARNING: Valgrind encountered a stack trace which has ==3843== no function names nor object file names. ==3843== Unless your program has a dynamically generated code (e.g. it is a JIT) ==3843== something is very much wrong with your binary's debug info. ==3843== See https://bugs.kde.org/show_bug.cgi?id=265803 and b/3423996 ==3843== ==3843== ==3843== ==3843== Process terminating with default action of signal 11 (SIGSEGV) ==3843== Bad permissions for mapped region at address 0x0 ==3843== at 0x0: ??? ==3843== ==3843== HEAP SUMMARY: ==3843== in use at exit: 0 bytes in 0 blocks ==3843== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==3843== ==3843== All heap blocks were freed -- no leaks are possible ==3843== ==3843== For counts of detected and suppressed errors, rerun with: -v ==3843== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) [1] + Stopped (signal) valgrind ls # valgrind: the 'impossible' happened: main(): signal was supposed to be fatal ==3843== at 0x3803F12C: ??? (in /system/lib/valgrind/memcheck-arm-linux) sched status: running_tid=1 Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. [1] Done(1) valgrind ls # Any clue on this? Thanks! (In reply to comment #39) > The Android port of Valgrind is now available here: > http://source.android.com/ > http://android.git.kernel.org/?p=platform/external/valgrind.git How do I build this? I did $ git clone git://android.git.kernel.org/platform/external/valgrind & cd valgrind $ ../../android-ndk-r5c/ndk-build Android NDK: Could not find application project directory ! Android NDK: Please define the NDK_PROJECT_PATH variable to point to it. /home/vmuser/Android/android-ndk-r5c/build/core/build-local.mk:85: *** Android NDK: Aborting . Stop. and no amount of clowning around with paths etc makes it want to cooperate. (In reply to comment #45) > > The Android port of Valgrind is now available here: > > How do I build this? I did More generally, could you please post a short summary of how to build this, how to install and run it, and what systems/setups/Android versions it works with. I think that would be a good thing to have. I did not investigate building it with NDK. The best way I know of is checking out and building the whole Android source following these instructions: http://source.android.com/source/downloading.html http://source.android.com/source/building.html Then you can rebuild just Valgrind with "mmm external/valgrind -jXX" and find the binaries in out/target/product/XX/system/{bin,lib}/valgrind. Maybe a little additional info, iirc, in my setup, even if I compile the whole android, it will not includes Valgrind in the system (but it still compiles Valgrind). So I need to transfer (using adb) the library (/system/lib) and the binary myself. I've tested Valgrind on Gingerbread and it works OK. P/s: It will take a while to compile Android (a couple of hours on my normal PC). The ldrexd/strexd patch (2011-02-11) only seems to do the ARM encoding of ldrexd/strexd I think I should post here how I build Valgrind for Android (maybe not the fastest way but for me the easiest). $ repo init -u git://android.git.kernel.org/platform/manifest.git $ repo sync $ source build/envsetup.sh $ lunch full-eng $ make -j8 $ mmm external/valgrind -j8 The binaries will be at: out/target/product/generic/system/bin/valgrind out/target/product/generic/system/lib/valgrind/* More info at: http://source.android.com Created attachment 61530 [details] Thumb ldrexd and strexd Hi, This is a patch to add thumb mode ldrexd and strexd; it's built on top of Jeff's patch in comment #4 (which you will need) and you'll also need Igor's fix from #43 Dave (In reply to comment #7) > Created an attachment (id=57141) [details] > Support ADDW on Thumb. Committed, r2170 (also the SUBW in comment #8). (In reply to comment #4, comment #43, comment #51) Support for {LD,ST}REX{,B,H,D} in both ARM and Thumb encodings, for NEON and non-NEON capable backends, was added in r2172, derived from these patches. Thanks. (In reply to comment #10) > Created an attachment (id=57144) [details] Committed as r11870 and 11871, thanks. btw the sigsuspend handler was not quite identical for ppc32-linux and x86-linux. (In reply to comment #11) > Created an attachment (id=57166) [details] > Configure-time temporary directory support Committed, r11881. Anyone can help me? I compiled the valgrind for android .(In reply to comment #50) But When I run the command valgrind after I put the *.so and bin file into android terminal, I meet a problem here, valgrind: failed to start tool 'memcheck' for platform 'arm-linux': No such file or directory " Anyone compiled it ok,and run ok? can you send the sources to me? > I think I should post here how I build Valgrind for Android (maybe not the > fastest way but for me the easiest). > > $ repo init -u git://android.git.kernel.org/platform/manifest.git > $ repo sync > $ source build/envsetup.sh > $ lunch full-eng > $ make -j8 > $ mmm external/valgrind -j8 > > The binaries will be at: > out/target/product/generic/system/bin/valgrind > out/target/product/generic/system/lib/valgrind/* > > More info at: > http://source.android.com (In reply to comment #56) > Anyone can help me? > I compiled the valgrind for android .(In reply to comment #50) > But When I run the command valgrind after I put the *.so and bin file into > android terminal, I meet a problem here, Where did you put the libraries? Make sure it's placed in /system/lib/valgrind/ As of trunk svn revision r11891, it is possible to cross-compile the trunk for Android, and get something that works. Check out the trunk and follow the instructions in README.android. Feedback welcomed. Thanks, Julian. (In reply to comment #57) > (In reply to comment #56) > > Anyone can help me? > > I compiled the valgrind for android .(In reply to comment #50) > > But When I run the command valgrind after I put the *.so and bin file into > > android terminal, I meet a problem here, > > Where did you put the libraries? Make sure it's placed in /system/lib/valgrind/ Maybe I make a mistake,I put all the libraries into /system/lib/ and put the valgrind into /system/bin/ You mean I should copy the all libraries which under folder into /system/lib/valgrind/? I will try Thank you very much Hi, Do we have some plans to support ARMv5 instruction set, I have tried to run valgrind on an ARMv5 based android system, it always crashed due to SIGILL, thanks. Thanks for this incredible work. I managed to make it work on my phone (HTC Desire). However, how do you manage to profile an Android Activity with native code (through NDK)? More specifically a NativeActivity? I tried all what I could to make it work (e.g. using app_process to run Activity) but could make it. I am wondering if this is even possible as activities runs on the Dalvik JVM (which itself calls NDK native code). Indeed, I am thinking its process preexist in memory whereas valgrind is required to launch a process to monitor it... The only solution I could see is maybe to fork a process from native code. Any information or idea? Thanks in advance (for your answer and work ;))! It is possible to run Valgrind on individual applications by making some changes to the Zygote. These changes have already been incorporated into the Android master tree. I've been planning to backport the patches to AOSP but so far haven't had the time. (In reply to comment #63) > It is possible to run Valgrind on individual applications by making some > changes to the Zygote. These changes have already been incorporated into the > Android master tree. Jeff, could you please make those patches available here? As per comment #62 I too have been looking for a way to do this, so far without success, so it would be great to see your solution. I'll post a link here when I upload the patches to AOSP. It's non-trivial. (In reply to comment #65) Jeff, do you have any approximate feel for when these changes would become publically available? These three patches modify the Zygote to enable debug instrumentation. I haven't tested them a whole lot. https://review.source.android.com/24891 https://review.source.android.com/24892 https://review.source.android.com/24893 You'll need to build a custom system image with the changes. To run Valgrind on the system server: adb root adb shell setprop wrap.system_server "logwrapper valgrind" adb shell stop && adb shell start To run Valgrind on an application: adb root adb shell setprop wrap.<process_name> "logwrapper valgrind" Truncate the combined property name "wrap." + the process name to 31 chars if needed. The system property server has a maximum length limit on property names. Of course you can pass other arguments to valgrind or run other tools instead. You MUST have root for this to work. Yes, I have exactly the same issue. Can anyone help us? (In reply to comment #44) > dear all, > i build valgrind on android2.3, then i tried this "valgrind ls", > 'the 'impossible' happened': > > > # valgrind ls > ==3843== Memcheck, a memory error detector > ==3843== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. > ==3843== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info > ==3843== Command: ls > ==3843== > ==3843== Invalid write of size 4 > ==3843== at 0xB00065E0: ??? (in /system/bin/linker) > ==3843== Address 0xafd4d484 is not stack'd, malloc'd or (recently) free'd > ==3843== > ==3843== > ==3843== > ==3843== > ==3843== WARNING: Valgrind encountered a stack trace which has > ==3843== no function names nor object file names. > ==3843== Unless your program has a dynamically generated code (e.g. it is a > JIT) > ==3843== something is very much wrong with your binary's debug info. > ==3843== See https://bugs.kde.org/show_bug.cgi?id=265803 and b/3423996 > ==3843== > ==3843== > ==3843== > ==3843== Process terminating with default action of signal 11 (SIGSEGV) > ==3843== Bad permissions for mapped region at address 0x0 > ==3843== at 0x0: ??? > ==3843== > ==3843== HEAP SUMMARY: > ==3843== in use at exit: 0 bytes in 0 blocks > ==3843== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > ==3843== > ==3843== All heap blocks were freed -- no leaks are possible > ==3843== > ==3843== For counts of detected and suppressed errors, rerun with: -v > ==3843== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) > [1] + Stopped (signal) valgrind ls > # > valgrind: the 'impossible' happened: > main(): signal was supposed to be fatal > ==3843== at 0x3803F12C: ??? (in /system/lib/valgrind/memcheck-arm-linux) > > sched status: > running_tid=1 > > > Note: see also the FAQ in the source distribution. > It contains workarounds to several common problems. > In particular, if Valgrind aborted or crashed after > identifying problems in your program, there's a good chance > that fixing those problems will prevent Valgrind aborting or > crashing, especially if it happened in m_mallocfree.c. > > If that doesn't help, please report this bug to: www.valgrind.org > > In the bug report, send all the above text, the valgrind > version, and what OS and version you are using. Thanks. > > > [1] Done(1) valgrind ls > # > > > > Any clue on this? > Thanks! (In reply to comment #68) > Yes, I have exactly the same issue. > Can anyone help us? Did you follow the build instructions on comment #58? > > ==3843== WARNING: Valgrind encountered a stack trace which has > > ==3843== no function names nor object file names. > > ==3843== Unless your program has a dynamically generated code (e.g. it is a > > JIT) > > ==3843== something is very much wrong with your binary's debug > > info. I don't think the trunk version of valgrind has any such message. Thanks a lot for you information. The reason I' (In reply to comment #69) > (In reply to comment #68) > > Yes, I have exactly the same issue. > > Can anyone help us? > > Did you follow the build instructions on comment #58? > > > > ==3843== WARNING: Valgrind encountered a stack trace which has > > > ==3843== no function names nor object file names. > > > ==3843== Unless your program has a dynamically generated code (e.g. it is a > > > JIT) > > > ==3843== something is very much wrong with your binary's debug > > > info. > > I don't think the trunk version of valgrind has any such message. Thanks a lot for you information. The version I am using is http://android.git.kernel.org/?p=platform/external/valgrind.git;a=summary. Jeff Brown and Kenny Root has already port it to android build system. I have debug it and found the reason. The reason is: In linux, every thread has its TLS area. In some of the ARMv6 or later version, the CPU has the TLS register, which is in CP15, c13. The other versions do not have this hardware register. If has no this register, the kernel will store the TLS area start address in 0xffff0ff0 address and provide a helper function named __kuser_get_tls at address 0xffff0fe0 to get the value. These addresses are also mapped as read only to "userspace" as it is a vector area of the kernel. From userspace's view, if the application want to set the TLS value, it use the system call 0xf005 to let the kernel write the address 0xffff0ff0. If the application want to get the TLS value, it will access the 0xffff0fe0 address directly to call the helper function. I find that, if the program sun on valgrind, the set_tls can work, but the get_tls can not, if the CPU has no TLS hardware register. Since the libc will intialize the TLS and set the errno.(The errno is at offset 8 of TLS area). Before set any value to errno, it first will get the TLS area address, then plus 8 to get the errno address. But this address is wrong, the value is 0xafd4d484, which we have already seen in the wrong info. I also write a bare metal program (do not use libc) to confirm this issue. This program will set_tls and then get_tls and write the value to the tls area. Without valgrind, it runs well, but with valgrind, it will crashes. In my opinion, maybe you test the valgrind on arm Android with the CPU that has the TLS register. And it has no such issue. I do not know how to attach my bare metal program here. Thanks a lot. Best Regards Richard LIU (In reply to comment #69) > (In reply to comment #68) > > Yes, I have exactly the same issue. > > Can anyone help us? > > Did you follow the build instructions on comment #58? > > > > ==3843== WARNING: Valgrind encountered a stack trace which has > > > ==3843== no function names nor object file names. > > > ==3843== Unless your program has a dynamically generated code (e.g. it is a > > > JIT) > > > ==3843== something is very much wrong with your binary's debug > > > info. > > I don't think the trunk version of valgrind has any such message. Which CPU are you using that doesn't have the TLS register? I was under the impression that it's in all ARMv6 and later CPUs. Note that bionic libc will enable the code path that uses the kernel vector area if you don't define "ARCH_ARM_HAVE_TLS_REGISTER" If you look at the area of the code in Valgrind where this is handled, it appears that they tried to support it but gave up and just said ARMv5 wouldn't be supported. Thanks for you information. My CPU is MSM7x27, and the application ARM is ARM1136JF-S. Seems the TLS register does not work. For ARM1136, the user guide for ARM site says: this register is only available from the rev1 (r1p0) release of the ARM1136JF-S processor. I have no idea about the detail of Valgrind, such as how valgrind handles this. Since the application can access the vector area directly with read only mode, just like its own VMA areas, if it does not run on valgrind. What is the difference between accessing vector area and its own VMA areas while running on valgrind? Best Regards (In reply to comment #72) > Which CPU are you using that doesn't have the TLS register? I was under the > impression that it's in all ARMv6 and later CPUs. Note that bionic libc will > enable the code path that uses the kernel vector area if you don't define > "ARCH_ARM_HAVE_TLS_REGISTER" > > If you look at the area of the code in Valgrind where this is handled, it > appears that they tried to support it but gave up and just said ARMv5 wouldn't > be supported. Hi Jeff,
I had integrated patch 24891, 24892 and 24893 into our system.img.
But when I execute "adb shell setprop wrap.com.android.browser "logwrapper valgrind"", I always encounter following exception.
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 2086, tid: 2086 >>> /system/bin/dexopt <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadd00d
r0 fffffe88 r1 deadd00d r2 00000026 r3 00000000
r4 800a5618 r5 000376d8 r6 00000000 r7 fffffe88
r8 00000000 r9 00000000 10 00000000 fp 00000000
ip 800a5724 sp bef919e8 lr afd193f5 pc 80045cca cpsr 20000030
d0 0000000000000000 d1 0000000000000000
d2 0000000000000000 d3 0000000000000000
d4 0000000000000000 d5 0000000000000000
d6 0000000000000000 d7 0000000000000000
d8 0000000000000000 d9 0000000000000000
d10 0000000000000000 d11 0000000000000000
d12 0000000000000000 d13 0000000000000000
d14 0000000000000000 d15 0000000000000000
scr 00000000
#00 pc 00045cca /system/lib/libdvm.so /system/lib/libdvm.so dvmAbort
#01 pc 00045414 /system/lib/libdvm.so /system/lib/libdvm.so dvmThrowChainedException
#02 pc 0004547c /system/lib/libdvm.so /system/lib/libdvm.so dvmThrowChainedExceptionWithClassMessage
#03 pc 0006ac68 /system/lib/libdvm.so /system/lib/libdvm.so dvmInitClass
#04 pc 0006aeaa /system/lib/libdvm.so /system/lib/libdvm.so dvmFindSystemClassNoInit
#05 pc 0006aec2 /system/lib/libdvm.so /system/lib/libdvm.so dvmFindSystemClass
#06 pc 0004541a /system/lib/libdvm.so /system/lib/libdvm.so dvmThrowChainedException
#07 pc 0004547c /system/lib/libdvm.so /system/lib/libdvm.so dvmThrowChainedExceptionWithClassMessage
#08 pc 0006ac68 /system/lib/libdvm.so /system/lib/libdvm.so dvmInitClass
#09 pc 0006aeaa /system/lib/libdvm.so /system/lib/libdvm.so dvmFindSystemClassNoInit
#10 pc 0006aec2 /system/lib/libdvm.so /system/lib/libdvm.so dvmFindSystemClass
#11 pc 0005b6b0 /system/lib/libdvm.so /system/lib/libdvm.so dvmCheckOptHeaderAndDependencies
#12 pc 0005b942 /system/lib/libdvm.so /system/lib/libdvm.so dvmCheckOptHeaderAndDependencies
#13 pc 0005bbd0 /system/lib/libdvm.so /system/lib/libdvm.so dvmContinueOptimization
#14 pc 00009006 /system/bin/dexopt /system/bin/dexopt
#15 pc 000091c2 /system/bin/dexopt /system/bin/dexopt
#16 pc 00014e34 /system/lib/libc.so /system/lib/libc.so __libc_init
code around pc:
80045ca8 2006447a ed14f7d1 20004c09 ee0cf7d1
80045cb8 447c4808 6bdb5823 d0002b00 49064798
80045cc8 700a2226 ee8af7d1 000439f1 000455af
80045cd8 0005f95a fffffe88 deadd00d b510b40e
80045ce8 4c0a4b09 b083447b aa05591b ca026b5b
code around lr:
afd193d4 447b4a0d 589cb083 90012600 686768a5
afd193e4 220ce008 2b005eab 1c28d003 47889901
afd193f4 35544306 d5f43f01 2c006824 b003d1ee
afd19404 bdf01c30 0002814a ffffff88 1c0fb5f0
afd19414 1c3db087 a9044355 1c16ac01 604d9004
stack:
bef919a8 c0000000
bef919ac 000000da
bef919b0 afd4272c
bef919b4 afd426d8
bef919b8 00000000
bef919bc afd193f5 /system/lib/libc.so
bef919c0 00000000
bef919c4 afd18459 /system/lib/libc.so
bef919c8 000000e8
bef919cc 0005f95a
bef919d0 000376d8
bef919d4 00000000
bef919d8 fffffe88
bef919dc afd184b7 /system/lib/libc.so
bef919e0 df002777
bef919e4 e3a070ad
#00 bef919e8 8008c4ba /system/lib/libdvm.so
bef919ec 80045419 /system/lib/libdvm.so
#01 bef919f0 000376d8
bef919f4 8001f764 /system/lib/libdvm.so
bef919f8 000376d8
bef919fc 8008c4ba /system/lib/libdvm.so
bef91a00 00000000
bef91a04 80045481 /system/lib/libdvm.so
#02 bef91a08 800aad28
bef91a0c 0000d1a0
bef91a10 000000b5
bef91a14 8006ac6d /system/lib/libdvm.so
#03 bef91a18 c0000000
bef91a1c 000000da
bef91a20 00000000
bef91a24 8008c4ba /system/lib/libdvm.so
bef91a28 00000000
bef91a2c 00000000
bef91a30 00000000
bef91a34 00000000
bef91a38 00000722
bef91a3c 8008c4ba /system/lib/libdvm.so
bef91a40 000376c0
bef91a44 00000000
bef91a48 fffffe88
bef91a4c 8006aeaf /system/lib/libdvm.so
#04 bef91a50 8008c4ba /system/lib/libdvm.so
bef91a54 8006aec7 /system/lib/libdvm.so
#05 bef91a58 8008c4ba /system/lib/libdvm.so
bef91a5c 8004541f /system/lib/libdvm.so
#06 bef91a60 0000000f
bef91a64 8001f764 /system/lib/libdvm.so
bef91a68 000376c0
bef91a6c 8008c4ba /system/lib/libdvm.so
bef91a70 00000000
bef91a74 80045481 /system/lib/libdvm.so
#07 bef91a78 800aad28
bef91a7c 0000d1a0
bef91a80 000000b5
bef91a84 8006ac6d /system/lib/libdvm.so
#08 bef91a88 00030e88
bef91a8c 00030e88
bef91a90 00000820
bef91a94 8008a711 /system/lib/libdvm.so
bef91a98 00000000
bef91a9c 00000000
bef91aa0 000316b0
bef91aa4 00000000
bef91aa8 00006008
bef91aac bef91b68
bef91ab0 00016fe8
bef91ab4 00000001
bef91ab8 00016fe8
bef91abc 8006aeaf /system/lib/libdvm.so
#09 bef91ac0 bef91b68
bef91ac4 8006aec7 /system/lib/libdvm.so
#10 bef91ac8 bef91b68
bef91acc 8005b6b5 /system/lib/libdvm.so
#11 bef91ad0 416df008
bef91ad4 00000800
bef91ad8 00031608
bef91adc 000003c0
bef91ae0 bef91b68
bef91ae4 bef91b68
bef91ae8 00000001
bef91aec 00000001
bef91af0 00016fe8
bef91af4 8005b947 /system/lib/libdvm.so
#12 bef91af8 000001b4
bef91afc c0000000
bef91b00 6f78c38b
bef91b04 0000003f
bef91b08 00000000
bef91b0c bef91b68
bef91b10 0012e598
bef91b14 00016fe8
bef91b18 0000000d
bef91b1c 00000000
bef91b20 0000000d
bef91b24 0012e598
bef91b28 00000028
bef91b2c 8005bbd5 /system/lib/libdvm.so
#13 bef91b30 0000000d
bef91b34 00000000
bef91b38 00000000
bef91b3c 415b0000
bef91b40 00016f90
bef91b44 415b0028
bef91b48 800a5618
bef91b4c 0012e5c0
bef91b50 00000028
bef91b54 800aad28
bef91b58 fffffe88
bef91b5c 80021064 /system/lib/libdvm.so
bef91b60 800aadd4
bef91b64 0000000d
bef91b68 000316b0
bef91b6c 800aadb0
bef91b70 4000c328
bef91b74 00000000
bef91b78 00000002
bef91b7c 8006b3e5 /system/lib/libdvm.so
bef91b80 800aad84
bef91b84 00000001
bef91b88 00000000
bef91b8c 8004601d /system/lib/libdvm.so
bef91b90 00000002
bef91b94 9673ac0d
bef91b98 0000b130
bef91b9c 00000000
bef91ba0 0000b130
bef91ba4 d0000000
bef91ba8 00000001
bef91bac 00009009 /system/bin/dexopt
#14 bef91bb0 3f1d28d8
bef91bb4 0ab84ae6
bef91bb8 00000001
bef91bbc b0010524
bef91bc0 bef91bd4
bef91bc4 0000000a
bef91bc8 bef91c68
bef91bcc 00000000
bef91bd0 3f1d28d8
bef91bd4 0ab84ae6
bef91bd8 bef91d7a
bef91bdc 0012e598
bef91be0 00000028
bef91be4 0000000d
bef91be8 40008000
bef91bec bef91dab
bef91bf0 b0009468
bef91bf4 0000a140
bef91bf8 bef91c44
bef91bfc 0000000a
bef91c00 bef91d63
bef91c04 000091c7 /system/bin/dexopt
#15 bef91c08 40008078
bef91c0c 00008a84 /system/bin/dexopt
bef91c10 0000000a
bef91c14 afd41524
bef91c18 bef91c70
bef91c1c afd14e37 /system/lib/libc.so
#16 bef91c20 00000000
bef91c24 00008a84 /system/bin/dexopt
bef91c28 00000000
bef91c2c 00000000
bef91c30 00000000
bef91c34 00000000
bef91c38 00000000
bef91c3c b0004fa5 /system/bin/linker
bef91c40 0000000a
bef91c44 bef91d50
bef91c48 bef91d63
bef91c4c bef91d69
bef91c50 bef91d6c
bef91c54 bef91d6f
bef91c58 bef91d72
bef91c5c bef91d7a
bef91c60 bef91d94
bef91c64 bef91d9f
There is no problem to execute valgrind on native linux process on our system, like "valgrind ls". but we can't execute valgrind on Android process with these patches, any idea?
The CPU core is ARM1136JF-S. System version is Android GingerBread 2.3.5.
Thanks.
(In reply to comment #67)
> These three patches modify the Zygote to enable debug instrumentation. I
> haven't tested them a whole lot.
>
> https://review.source.android.com/24891
> https://review.source.android.com/24892
> https://review.source.android.com/24893
>
> You'll need to build a custom system image with the changes.
>
> To run Valgrind on the system server:
>
> adb root
> adb shell setprop wrap.system_server "logwrapper valgrind"
> adb shell stop && adb shell start
>
> To run Valgrind on an application:
>
> adb root
> adb shell setprop wrap.<process_name> "logwrapper valgrind"
>
> Truncate the combined property name "wrap." + the process name to 31 chars if
> needed. The system property server has a maximum length limit on property
> names.
>
> Of course you can pass other arguments to valgrind or run other tools instead.
>
> You MUST have root for this to work.
Sam, You have some other problems like CheckJNI violations. You can see from the stack that Dalvik called dvmAbort because of some failure conditions. That function intentionally causes a SIGSEGV with the "deadd00d" fault address. Look further back in the logcat before the SIGSEGV and you'll find your real problem. Hi Kenny,
Here is the log before SIGSEGV.
The fail reason seems is NoClassDefFoundError.
ERROR/dalvikvm(2086): Too many exceptions during init (failed on 'Ljava/lang/NoClassDefFoundError;' 'java.lang.NoClassDefFoundError')
But I still have no idea for what lead to this error.
VERBOSE/ActivityManager(1746): Adding provider requested by com.android.launcher from process system
VERBOSE/ActivityManager(1746): Starting activity when config will change = false
INFO/ActivityManager(1746): Starting: Intent { act=android.intent.action.MAIN flg=0x10000000 cmp=com.android.browser/.BrowserActivity } from pid 1834
VERBOSE/ActivityManager(1746): Sending result to HistoryRecord{406bf7d0 com.android.launcher/com.android.launcher2.Launcher} (index 0)
VERBOSE/ActivityManager(1746): startActivity() => mUserLeaving=true
VERBOSE/ActivityManager(1746): Starting new activity HistoryRecord{405f73d0 com.android.browser/.BrowserActivity} in new task TaskRecord{4071c9b0 #3 A android.task.browser}
VERBOSE/ActivityManager(1746): Checking URI perm to null from Intent { act=android.intent.action.MAIN flg=0x10000000 cmp=com.android.browser/.BrowserActivity }; flags=0x10000000
VERBOSE/ActivityManager(1746): Prepare open transition: starting HistoryRecord{405f73d0 com.android.browser/.BrowserActivity}
VERBOSE/ActivityManager(1746): Resuming HistoryRecord{405f73d0 com.android.browser/.BrowserActivity}
VERBOSE/ActivityManager(1746): Skip resume: need to start pausing
VERBOSE/ActivityManager(1746): Start pausing: HistoryRecord{406bf7d0 com.android.launcher/com.android.launcher2.Launcher}
VERBOSE/ActivityManager(1746): Enqueueing pending pause: HistoryRecord{406bf7d0 com.android.launcher/com.android.launcher2.Launcher}
VERBOSE/ActivityManager(1746): Waiting for pause to complete...
ERROR/Process(1746): @@@@@ start processClass:android.app.ActivityThread
ERROR/Process(1746): @@@@@ start niceName:com.android.browser
ERROR/Process(1746): @@@@@ start zygoteArgs:null
VERBOSE/ActivityManager(1746): Activity paused: token=HistoryRecord{406bf7d0 com.android.launcher/com.android.launcher2.Launcher}, icicle=Bundle[mParcelledData.dataSize=3692], timeout=false
VERBOSE/ActivityManager(1746): Complete pause: HistoryRecord{406bf7d0 com.android.launcher/com.android.launcher2.Launcher}
VERBOSE/ActivityManager(1746): Enqueueing pending stop: HistoryRecord{406bf7d0 com.android.launcher/com.android.launcher2.Launcher}
VERBOSE/ActivityManager(1746): Resuming HistoryRecord{405f73d0 com.android.browser/.BrowserActivity}
VERBOSE/ActivityManager(1746): Resuming top, waiting visible to hide: HistoryRecord{406bf7d0 com.android.launcher/com.android.launcher2.Launcher}
VERBOSE/ActivityManager(1746): Prepare open transition: prev=HistoryRecord{406bf7d0 com.android.launcher/com.android.launcher2.Launcher}
VERBOSE/ActivityManager(1746): startProcess: name=com.android.browser app=null knownToBeDead=true thread=null pid=-1
VERBOSE/ActivityManager(1746): Clearing bad process: 10016/com.android.browser
ERROR/ActivityManager(1746): Process.start app.processNamecom.android.browser
WARN/Zygote(1734): @@@@@ runOnce parsedArgs com.android.internal.os.ZygoteConnection$Arguments@40515298
WARN/Zygote(1734): @@@@@ applyInvokeWithSystemProperty property:wrap.com.android.browser
WARN/Zygote(2074): @@@@@ Process.setArgV0 niceName:com.android.browser
WARN/Zygote(2074): @@@@@ WrapperInit.execApplication niceName:com.android.browser
WARN/Zygote(2074): @@@@@ WrapperInit.execApplication remainingArgs:[Ljava.lang.String;@40515450
INFO/dalvikvm(2074): @@@@@ Exec argp[0] /system/bin/sh:
INFO/dalvikvm(2074): @@@@@ Exec argp[1] -c:
INFO/dalvikvm(2074): @@@@@ Exec argp[2] logwrapper valgrind /system/bin/app_process /system/bin --application '--nice-name=com.android.browser' com.android.internal.os.WrapperInit 23 'android.app.ActivityThread':
INFO/dalvikvm(2074): Exec: /system/bin/sh -c logwrapper valgrind /system/bin/app_process /system/bin --application '--nice-name=com.android.browser' com.android.internal.os.WrapperInit 23 'android.app.ActivityThread'
DEBUG/Wrapper(2074): @@@@@ execApplication Zygote.execShell command:logwrapper valgrind /system/bin/app_process /system/bin --application '--nice-name=com.android.browser' com.android.internal.os.WrapperInit 23 'android.app.ActivityThread'
INFO/valgrind(2080): ==2081== Memcheck, a memory error detector
INFO/valgrind(2080): ==2081== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
INFO/valgrind(2080): ==2081== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
INFO/valgrind(2080): ==2081== Command: /system/bin/app_process /system/bin --application --nice-name=com.android.browser com.android.internal.os.WrapperInit 23 android.app.ActivityThread
INFO/valgrind(2080): ==2081==
DEBUG/AndroidRuntime(2081): >>>>>> AndroidRuntime START com.android.internal.os.RuntimeInit <<<<<<
DEBUG/AndroidRuntime(2081): CheckJNI is ON
INFO/AndroidRuntime(2081): JNI options: '-Xjniopts:warnonly'
WARN/dalvikvm(2081): mmap(3372, R, FILE|SHARED, 12, 1859584) failed: Invalid argument
WARN/dalvikvm(2081): Zip: cd map failed
DEBUG/dalvikvm(2081): Unable to process classpath element '/system/framework/core.jar'
WARN/dalvikvm(2081): mmap(3407, R, FILE|SHARED, 12, 286720) failed: Invalid argument
WARN/dalvikvm(2081): Zip: cd map failed
DEBUG/dalvikvm(2081): Unable to process classpath element '/system/framework/bouncycastle.jar'
INFO/dalvikvm(2081): DexOpt: Some deps went away
DEBUG/dalvikvm(2081): ODEX file is stale or bad; removing and retrying (/data/dalvik-cache/system@framework@ext.jar@classes.dex)
DEBUG/dalvikvm(2081): DexOpt: --- BEGIN 'ext.jar' (bootstrap=1) ---
INFO/valgrind(2080): ==2086== Memcheck, a memory error detector
INFO/valgrind(2080): ==2086== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
INFO/valgrind(2080): ==2086== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
INFO/valgrind(2080): ==2086== Command: /system/bin/app_process /system/bin --application --nice-name=com.android.browser com.android.internal.os.WrapperInit 23 android.app.ActivityThread
INFO/valgrind(2080): ==2086== Parent PID: 2081
INFO/valgrind(2080): ==2086==
INFO/valgrind(2080): ==2086== execv called - the tool will now quit
ERROR/dalvikvm(2086): Too many exceptions during init (failed on 'Ljava/lang/NoClassDefFoundError;' 'java.lang.NoClassDefFoundError')
ERROR/dalvikvm(2086): VM aborting
INFO/DEBUG(1289): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
(In reply to comment #75)
> Sam,
>
> You have some other problems like CheckJNI violations. You can see from the
> stack that Dalvik called dvmAbort because of some failure conditions. That
> function intentionally causes a SIGSEGV with the "deadd00d" fault address.
>
> Look further back in the logcat before the SIGSEGV and you'll find your real
> problem.
(In reply to comment #67) > https://review.source.android.com/24891 > https://review.source.android.com/24892 > https://review.source.android.com/24893 review.source.android.com appears to have been unavailable for about the last 3 days at least. Has it been renamed or moved, or some such? (In reply to comment #77) > > review.source.android.com appears to have been unavailable for about > the last 3 days at least. Has it been renamed or moved, or some such? Apparently android.git.kernel.org and review.source.android.com are offline due to the recent kernel.org security breach. I also need these three patches to test my program. Could someone who already has it send it to me? Thanks very much in advance. https://review.source.android.com/24891 https://review.source.android.com/24892 https://review.source.android.com/24893 Best Regards Richard LIu (In reply to comment #78) > (In reply to comment #77) > > > > review.source.android.com appears to have been unavailable for about > > the last 3 days at least. Has it been renamed or moved, or some such? > > Apparently android.git.kernel.org and review.source.android.com are offline due > to the recent kernel.org security breach. I have the same issue in android emulator too. Can anyone help me? (In reply to comment #44) > dear all, > i build valgrind on android2.3, then i tried this "valgrind ls", > 'the 'impossible' happened': > > > # valgrind ls > ==3843== Memcheck, a memory error detector > ==3843== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. > ==3843== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info > ==3843== Command: ls > ==3843== > ==3843== Invalid write of size 4 > ==3843== at 0xB00065E0: ??? (in /system/bin/linker) > ==3843== Address 0xafd4d484 is not stack'd, malloc'd or (recently) free'd > ==3843== > ==3843== > ==3843== > ==3843== > ==3843== WARNING: Valgrind encountered a stack trace which has > ==3843== no function names nor object file names. > ==3843== Unless your program has a dynamically generated code (e.g. it is a > JIT) > ==3843== something is very much wrong with your binary's debug info. > ==3843== See https://bugs.kde.org/show_bug.cgi?id=265803 and b/3423996 > ==3843== > ==3843== > ==3843== > ==3843== Process terminating with default action of signal 11 (SIGSEGV) > ==3843== Bad permissions for mapped region at address 0x0 > ==3843== at 0x0: ??? > ==3843== > ==3843== HEAP SUMMARY: > ==3843== in use at exit: 0 bytes in 0 blocks > ==3843== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > ==3843== > ==3843== All heap blocks were freed -- no leaks are possible > ==3843== > ==3843== For counts of detected and suppressed errors, rerun with: -v > ==3843== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) > [1] + Stopped (signal) valgrind ls > # > valgrind: the 'impossible' happened: > main(): signal was supposed to be fatal > ==3843== at 0x3803F12C: ??? (in /system/lib/valgrind/memcheck-arm-linux) > > sched status: > running_tid=1 > > > Note: see also the FAQ in the source distribution. > It contains workarounds to several common problems. > In particular, if Valgrind aborted or crashed after > identifying problems in your program, there's a good chance > that fixing those problems will prevent Valgrind aborting or > crashing, especially if it happened in m_mallocfree.c. > > If that doesn't help, please report this bug to: www.valgrind.org > > In the bug report, send all the above text, the valgrind > version, and what OS and version you are using. Thanks. > > > [1] Done(1) valgrind ls > # > > > > Any clue on this? > Thanks! (In reply to comment #80) > I have the same issue in android emulator too. There were a few bugs where valgrind's debuginfo reader assumed that it could perform un-aligned memory references (fetch an 'int' from an address that is not 0 mod 4) and get the correct contents. This does not work on ARM. The hardware does not trap, but the result is equivalent to garbage unless the code takes explicit action to fix it. https://bugs.kde.org/show_bug.cgi?id=282527 https://bugs.kde.org/show_bug.cgi?id=283154 In particular the source to valgrind must be at r12083 or later, and valgrind-3.6.1 does not have those fixes. Re-build valgrind from current svn repository source [takes 1/2 hour if you follow the directions], or wait for release 3.7.0, which should appear soon (in about two weeks?) hi ,thanks fr your information. but I have something that can not understand. you refereed that "Re-build valgrind from current svn repository source", Can the complied result run in android ? now I just complied the valgrind of android porting. (In reply to comment #81) > (In reply to comment #80) > > I have the same issue in android emulator too. > > There were a few bugs where valgrind's debuginfo reader assumed that it could > perform un-aligned memory references (fetch an 'int' from an address that is > not 0 mod 4) and get the correct contents. This does not work on ARM. The > hardware does not trap, but the result is equivalent to garbage unless the code > takes explicit action to fix it. > > https://bugs.kde.org/show_bug.cgi?id=282527 > https://bugs.kde.org/show_bug.cgi?id=283154 > In particular the source to valgrind must be at r12083 or later, and > valgrind-3.6.1 does not have those fixes. > > Re-build valgrind from current svn repository source [takes 1/2 hour if you > follow the directions], or wait for release 3.7.0, which should appear soon (in > about two weeks?) (In reply to comment #82) > Can the complied result run in android ? Get the svn source (either top-of-trunk, or branches/VALGRIND_3_7_BRANCH.) Follow the directions in README.android: How to cross-compile for Android. These notes were last updated on 27 Sept 2011, for Valgrind SVN revision 12060/2209. If you cannot do that, then wait for release 3.7.0 (current estimate: about two weeks.) hi,thanks for your replying. I complied the valgrind source followed the README.android. also I have some errors when testing the valgrind on NEXUX_S(the android os is 2.3.7),here is the erros:(the test code wad complied under the android source tree, should it complied by NDK?) # /data/local/Inst/bin/valgrind /data/local/testleak ==9327== Memcheck, a memory error detector ==9327== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==9327== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info ==9327== Command: /data/local/testleak ==9327== ==9327== Conditional jump or move depends on uninitialised value(s) ==9327== at 0xB0005E34: ??? (in /system/bin/linker) ==9327== ==9327== Conditional jump or move depends on uninitialised value(s) ==9327== at 0xB0005E38: ??? (in /system/bin/linker) ==9327== link_image[1947]: 9327 could not load needed library '/data/local/Inst/lib/valgrind/vgpreload_core-arm-linux.so' for '/data/local/testleak' (reloc_library[1311]: 9327 cannot locate '__cxa_finalize'... )CANNOT LINK EXECUTABLE (In reply to comment #83) > (In reply to comment #82) > > Can the complied result run in android ? > > Get the svn source (either top-of-trunk, or branches/VALGRIND_3_7_BRANCH.) > Follow the directions in README.android: > How to cross-compile for Android. These notes were last updated on > 27 Sept 2011, for Valgrind SVN revision 12060/2209. > If you cannot do that, then wait for release 3.7.0 (current estimate: about two > weeks.) Hi, dear Jeff Brown The google gerrit server are still out of service. And I need these three patches in my work. Have these three patches merged into the git tree? As the git server seems work now. Thanks very much in advance. Best Regards Richard LIU (In reply to comment #67) > These three patches modify the Zygote to enable debug instrumentation. I > haven't tested them a whole lot. > > https://review.source.android.com/24891 > https://review.source.android.com/24892 > https://review.source.android.com/24893 > > You'll need to build a custom system image with the changes. > > To run Valgrind on the system server: > > adb root > adb shell setprop wrap.system_server "logwrapper valgrind" > adb shell stop && adb shell start > > To run Valgrind on an application: > > adb root > adb shell setprop wrap.<process_name> "logwrapper valgrind" > > Truncate the combined property name "wrap." + the process name to 31 chars if > needed. The system property server has a maximum length limit on property > names. > > Of course you can pass other arguments to valgrind or run other tools instead. > > You MUST have root for this to work. Hello Kenny, We got the same problem in 3.7.0. Our CPU doesn’t have TLS register so we disabled this option in the kernel configuration. As a result the “ARCH_ARM_HAVE_TLS_REGISTER” is not defined when building bionic. The message from valgrild was very similar like as before one. Somewhere in __libc_init_common (0xAFD22F5A) try to read some data which is located address 0x00 (maybe a NULL). The target program, helloworld, works fine without valgrind but it crashed inside in valgrind. So, could you tell me where should I start to investigate this problem? I mean, I’d like to see the related code as you pointed out. “ If you look at the area of the code in Valgrind where this is handled, it appears that they tried to support it but gave up and just said ARMv5 wouldn't be supported. “ ==3754== Memcheck, a memory error detector ==3754== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==3754== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==3754== Command: system_server ==3754== ==3754== Invalid read of size 4 ==3754== at 0xAFD22F5A: __libc_init_common (in /system/lib/libc.so) ==3754== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==3754== ==3754== ==3754== ==3754== ==3754== WARNING: Valgrind encountered a stack trace which has ==3754== no function names nor object file names. ==3754== Unless your program has a dynamically generated code (e.g. it is a JIT) ==3754== something is very much wrong with your binary's debug info. ==3754== See https://bugs.kde.org/show_bug.cgi?id=265803 and b/3423996 ==3754== ==3754== ==3754== ==3754== Process terminating with default action of signal 11 (SIGSEGV) ==3754== Bad permissions for mapped region at address 0x0 ==3754== at 0x0: ??? ==3754== ==3754== HEAP SUMMARY: ==3754== in use at exit: 0 bytes in 0 blocks ==3754== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==3754== ==3754== All heap blocks were freed -- no leaks are possible ==3754== ==3754== For counts of detected and suppressed errors, rerun with: -v ==3754== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) [1] + Stopped (signal) valgrind --leak-check=yes system_server # valgrind: the 'impossible' happened: main(): signal was supposed to be fatal ==3754== at 0x38036408: ??? (in /system/lib/valgrind/memcheck-arm-linux) sched status: running_tid=1 (In reply to comment #72) > Which CPU are you using that doesn't have the TLS register? I was under the > impression that it's in all ARMv6 and later CPUs. Note that bionic libc will > enable the code path that uses the kernel vector area if you don't define > "ARCH_ARM_HAVE_TLS_REGISTER" > If you look at the area of the code in Valgrind where this is handled, it > appears that they tried to support it but gave up and just said ARMv5 wouldn't > be supported. (In reply to comment #86) > Our CPU doesn’t have TLS register so we disabled this option in the kernel > configuration. > As a result the “ARCH_ARM_HAVE_TLS_REGISTER” is not defined when building > bionic. > > The message from valgrild was very similar like as before one. > Somewhere in __libc_init_common (0xAFD22F5A) try to read some data which is > located address 0x00 (maybe a NULL). The fix is in atttachment https://bugs.kde.org/attachment.cgi?id=64147 to Bug 276897 (ARM v6 legacy patches), specifically file coregrind/m_dispatch/dispatch-arm-linux.S at symbols __aeabi_read_tp and real_sys_set_tls, and their callers. Thanks John! What a nice work you did! I’ll do it right now (In reply to comment #87) > (In reply to comment #86) > > Our CPU doesn’t have TLS register so we disabled this option in the kernel > > configuration. > > As a result the “ARCH_ARM_HAVE_TLS_REGISTER” is not defined when building > > bionic. > > > > The message from valgrild was very similar like as before one. > > Somewhere in __libc_init_common (0xAFD22F5A) try to read some data which is > > located address 0x00 (maybe a NULL). > The fix is in atttachment https://bugs.kde.org/attachment.cgi?id=64147 to Bug > 276897 (ARM v6 legacy patches), specifically file > coregrind/m_dispatch/dispatch-arm-linux.S at symbols __aeabi_read_tp and > real_sys_set_tls, and their callers. Hi John, Unfortunately, we are failed to run valgrind after apply your patches. TLS handling: https://bugs.kde.org/attachment.cgi?id=64147 Offset define: https://bugs.kde.org/attachment.cgi?id=64149 It seems like a system hang, looks like a busy loop. No reaction from device including keyboard input. the valgrind output is like bellow # ./valgrind -v /data/local/Inst/leak_test ==2420== Memcheck, a memory error detector ==2420== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==2420== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info ==2420== Command: /data/local/Inst/leak_test ==2420== --2420-- Valgrind options: --2420-- -v --2420-- Contents of /proc/version: --2420-- Linux version 2.6.34 (-) (gcc version 4.4.0 (GCC) ) #1 SMP Tue Jan 17 11:24:54 KST 2012 --2420-- Arch and hwcaps: ARM, ARMv7-vfp --2420-- Page sizes: currently 4096, max supported 4096 --2420-- Valgrind library directory: /data/local/Inst/lib/valgrind --2420-- Reading syms from /data/local/Inst/leak_test (0x8000) --2420-- Reading syms from /data/local/Inst/lib/valgrind/memcheck-arm-linux (0x38000000) --2420-- object doesn't have a dynamic symbol table --2420-- Reading syms from /system/bin/linker (0xb0001000) --2420-- object doesn't have a symbol table --2420-- object doesn't have a dynamic symbol table --2420-- Scheduler: using generic scheduler lock implementation. --2420-- Reading suppressions file: /data/local/Inst/lib/valgrind/default.supp And our CPU information is # cat /proc/cpuinfo Processor : ARMv7 Processor rev 1 (v7l) processor : 0 BogoMIPS : 1196.03 Features : swp half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part : 0xc09 CPU revision : 1 And I’ll attach the result of strace. So could you help us again? Davy Created attachment 68032 [details]
strace result
Have you tried just recompiling the kernel with CONFIG_TLS_REG_EMUL=n and CONFIG_HAS_TLS_REG=y ? I'm not familiar with any ARMv7 that doesn't have CP15. Hi Kenny, Thanks for your feedback. We’ll rebuild our kernel and test again but I have a few questions before do it. 1. Should I revert John’s patch? (now we are using rev. 12345) 2. after building kernel, it’ll be ok that rebuild only boinc? Davy (In reply to comment #90) In the strace output I see 3 calls to set_tls: set_tls(0xb00147dc, 0xc, 0xbe321de0, 0xb001556c, 0xb000c448) = 0 set_tls(0xafd4a864, 0xafd4a828, 0, 0x40, 0xafd42328) = 0 set_tls(0, 0xafd4a864, 0x3833b7ed, 0x1508, 0) = 0 with the first two near the beginning, and the last one very close to the end. The last call set_tls(0) obviously is a problem. Also, in the last call it is curious that the phantom second argument 0xafd4a864 is the same as the actual argument to the middle call set_tls(0xafd4a864). Could there be a typo in placing the argument into r0 ? My patches enable memcheck to run under Debian on NSLU2 and SheevaPlug, which are both vt5e devices. They are the only ARM hardware that I have. Sorry the patches don't work for you. I compiled Valgrind for Android (from AOSP sources for Galaxy Nexus). But when I want to use tool callgrind I get following error: 1|root@android:/ #valgrind --tool=callgrind --callgrind-out-file=/sdcard/out.callgrind ls ==2645== Callgrind, a call-graph generating cache profiler ==2645== Copyright (C) 2002-2010, and GNU GPL'd, by Josef Weidendorfer et al. ==2645== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==2645== Command: ls ==2645== --2645-- warning: can't write info file '/tmp/callgrind.info.2645' ==2645== For interactive control, run 'callgrind_control -h'. 0x0000b07d BB# 113811 Callgrind: external/valgrind/main/callgrind/jumps.c:164 (new_jcc): Assertion '(0 <= jmp) && (jmp <= from->bb->cjmp_count)' failed. ==2645== at 0x38024458: ??? (in /system/lib/valgrind/callgrind-arm-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==2645== at 0xB07C: ??? (in /system/bin/toolbox) How do I fix this error? Thanks in advance. (In reply to comment #94) > ==2645== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ... > Callgrind: external/valgrind/main/callgrind/jumps.c:164 (new_jcc): Assertion > '(0 <= jmp) && (jmp <= from->bb->cjmp_count)' failed. Please check out 3.7.0 or newer. See bug 265771: this problem has been fixed in 3.7.0. It is known to appear in 3.6.1 (see also bug 273465). A note: callgrind results currently do not make much sense on ARM. We are trying to improve it, but it's tricky. (In reply to comment #95) > (In reply to comment #94) > > ==2645== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info > ... > > Callgrind: external/valgrind/main/callgrind/jumps.c:164 (new_jcc): Assertion > > '(0 <= jmp) && (jmp <= from->bb->cjmp_count)' failed. > > Please check out 3.7.0 or newer. > See bug 265771: this problem has been fixed in 3.7.0. It is known > to appear in 3.6.1 (see also bug 273465). > > A note: callgrind results currently do not make much sense on ARM. > We are trying to improve it, but it's tricky. Could you tell me how long do you think it will take to make callgrind usable on ARM? Is it possible I will be able to use it before summer? Thank you for your time. |