Version: 3.6.0 OS: Linux We are in the process of bringing up Valgrind for Android on ARM. This bug is intended as a placeholder to gather related patches as we work through the issues systematically. We have implemented some missing instructions such as ldrexd, strexd, dmb st, addw, subw, and others. There are also some patches to syscall handling and miscellaneous patches for compiling with a BSD-like libc. Patches to follow shortly... Reproducible: Always
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.