|
From: Jun Y. <YJ...@gm...> - 2013-11-01 04:00:18
|
Hello everyone, I am pretty new to both Valgrind and Android -- recently I am working on using Valgrind to check the running of some Android apps. I have successfully built Valgrind as instructed in the README and pushed it into my emulator. I used "android setprop wrap...." to redirect the app to be launched through Valgrind, however, I am getting the following error for all the apps launched by Valgrind: ================from the logcat ================================= I/val.sh ( 1259): disInstr(thumb): unhandled instruction: 0xEEBA 0x7BEF I/val.sh ( 1259): ==1260== valgrind: Unrecognised instruction at address 0xcab86ad. I/val.sh ( 1259): ==1260== at 0xCAB86AC: ??? (in /system/lib/libjavacore.so) I/val.sh ( 1259): ==1260== Your program just tried to execute an instruction that Valgrind I/val.sh ( 1259): ==1260== 1. Your program has a bug and erroneously jumped to a non-code I/val.sh ( 1259): ==1260== location. If you are running Memcheck and you just saw a I/val.sh ( 1259): ==1260== warning about a bad jump, it's probably your program's fault. I/val.sh ( 1259): ==1260== 2. The instruction is legitimate but Valgrind doesn't handle it, I/val.sh ( 1259): ==1260== i.e. it's Valgrind's fault. If you think this is the case or I/val.sh ( 1259): ==1260== you are not sure, please let us know and we'll try to fix it. I/val.sh ( 1259): ==1260== Either way, Valgrind will now raise a SIGILL signal which will I/val.sh ( 1259): ==1260== probably kill your program. I/val.sh ( 1259): ==1260== Conditional jump or move depends on uninitialised value(s) I/val.sh ( 1259): ==1260== at 0x4005224: ??? (in /system/bin/linker) I/val.sh ( 1259): ==1260== F/libc ( 1260): Fatal signal 4 (SIGILL) at 0x0cadd8f0 (code=1), thread 1260 (m.gstar.wponlyn) I/val.sh ( 1259): disInstr(thumb): unhandled instruction: 0xEEBA 0x7BEF I/val.sh ( 1259): ==1260== valgrind: Unrecognised instruction at address 0xcab86ad. I/val.sh ( 1259): ==1260== valgrind: Unrecognised instruction at address 0xcab86ad. I/val.sh ( 1259): ==1260== at 0xCAB86AC: ??? (in /system/lib/libjavacore.so) I/val.sh ( 1259): ==1260== Your program just tried to execute an instruction that Valgrind I/val.sh ( 1259): ==1260== did not recognise. There are two possible reasons for this. I/val.sh ( 1259): ==1260== 1. Your program has a bug and erroneously jumped to a non-code I/val.sh ( 1259): ==1260== location. If you are running Memcheck and you just saw a I/val.sh ( 1259): ==1260== warning about a bad jump, it's probably your program's fault. I/val.sh ( 1259): ==1260== 2. The instruction is legitimate but Valgrind doesn't handle it, I/val.sh ( 1259): ==1260== i.e. it's Valgrind's fault. If you think this is the case or I/val.sh ( 1259): ==1260== you are not sure, please let us know and we'll try to fix it. I/val.sh ( 1259): ==1260== Either way, Valgrind will now raise a SIGILL signal which will I/val.sh ( 1259): ==1260== probably kill your program. I/val.sh ( 1259): ==1260== I/val.sh ( 1259): ==1260== Process terminating with default action of signal 4 (SIGILL) I/val.sh ( 1259): ==1260== Illegal opcode at address 0xCAB86AD I/val.sh ( 1259): ==1260== Process terminating with default action of signal 4 (SIGILL) I/val.sh ( 1259): ==1260== Illegal opcode at address 0xCAB86AD I/val.sh ( 1259): ==1260== at 0xCAB86AC: ??? (in /system/lib/libjavacore.so) I/val.sh ( 1259): ==1260== I/val.sh ( 1259): ==1260== HEAP SUMMARY: I/val.sh ( 1259): ==1260== in use at exit: 344,162 bytes in 842 blocks I/val.sh ( 1259): ==1260== total heap usage: 3,895 allocs, 3,053 frees, 2,512,927 bytes allocated I/val.sh ( 1259): ==1260== D/dalvikvm( 1210): GC_FOR_ALLOC freed 422K, 8% free 5276K/5724K, paused 591ms, total 802ms I/val.sh ( 1259): ==1260== LEAK SUMMARY: I/val.sh ( 1259): ==1260== definitely lost: 2,618 bytes in 66 blocks I/val.sh ( 1259): ==1260== indirectly lost: 26,528 bytes in 66 blocks I/val.sh ( 1259): ==1260== possibly lost: 7,526 bytes in 180 blocks I/val.sh ( 1259): ==1260== still reachable: 307,490 bytes in 530 blocks I/val.sh ( 1259): ==1260== suppressed: 0 bytes in 0 blocks I/val.sh ( 1259): ==1260== Rerun with --leak-check=full to see details of leaked memory I/val.sh ( 1259): ==1260== I/val.sh ( 1259): ==1260== Use --track-origins=yes to see where uninitialised values come from I/val.sh ( 1259): ==1260== ERROR SUMMARY: 9 errors from 3 contexts (suppressed: 0 from 0) ============================================================ after this point, the app is killed.... val.sh is the script that setprop used to launch app from valgrind. Can anyone help me out with this weird behavior? Thanks! |
|
From: John R.
|
> I have > successfully built Valgrind as instructed in the README and pushed it into > my emulator. I used "android setprop wrap...." to redirect the app to be > launched through Valgrind, however, I am getting the following error for all > the apps launched by Valgrind: > > ================from the logcat ================================= > I/val.sh ( 1259): disInstr(thumb): unhandled instruction: 0xEEBA 0x7BEF > I/val.sh ( 1259): ==1260== valgrind: Unrecognised instruction at address > 0xcab86ad. > I/val.sh ( 1259): ==1260== at 0xCAB86AC: ??? (in > /system/lib/libjavacore.so) You forgot to say which version of valgrind (run "valgrind --version") and which version of hardware (on Linux: "cat /proc/cpuinfo"). Assembling that unhandled Thumb-mode instruction 0xEEBA 0x7BEF: ----- foo.S .thumb_func abc: .short 0xEEBA, 0x7BEF ----- $ gcc -c foo.S $ gdb foo.o (gdb) x/i 1 0x1 <abc+1>: vcvt.f64.s32 d7, d7, #1 (gdb) x/x 0 0x0 <abc>: 0x7befeeba ----- So does your hardware have vector floating point to execute 'vcvt.f64.s32' ? The software believes (or was told) that the hardware does. Is it true? Check the configuration steps. Look for a file "config.h", and see if its contents describe your setup accurately. -- |
|
From: John R.
|
>> ================from the logcat ================================= >> I/val.sh ( 1259): disInstr(thumb): unhandled instruction: 0xEEBA 0x7BEF > 0x1 <abc+1>: vcvt.f64.s32 d7, d7, #1 Also note this bug which is fixed in valgrind-3.9.0: 308717 ARM: implement fixed-point VCVT.F64.[SU]32 |
|
From: Jun Y. <YJ...@gm...> - 2013-11-01 15:08:37
|
Thanks John. I was using 3.8. I will give 3.9 a try. John Reiser <jreiser <at> BitWagon.com> writes: > > >> ================from the logcat ================================= > >> I/val.sh ( 1259): disInstr(thumb): unhandled instruction: 0xEEBA 0x7BEF > > > 0x1 <abc+1>: vcvt.f64.s32 d7, d7, #1 > > Also note this bug which is fixed in valgrind-3.9.0: > 308717 ARM: implement fixed-point VCVT.F64.[SU]32 |
|
From: Horatio <vat...@ya...> - 2015-02-11 11:28:07
|
Hello everyone, I also got a similar error on my Samsung Galaxy S4(rooted). Could anyone help me? >From logcat: ====================================== I/start_valgrind.sh(31243): *disInstr(thumb): unhandled instruction: 0x4771 0x5F43* ... I/start_valgrind.sh(31243): start_valgrind.sh terminated by exit(10) ====================================== My Valgrind version is *valgrind-3.10.1*, built on Ubuntu 12.04 LTS(64bits) with android NDK r8e(64bits). My hardware info: ----------------------------------------------------------------------- 1|root@ja3g:/data/local/valdroid/bin # cat /proc/cpuinfo cat /proc/cpuinfo Processor : ARMv7 Processor rev 2 (v7l) processor : 0 BogoMIPS : 1590.88 processor : 1 BogoMIPS : 1590.88 processor : 2 BogoMIPS : 1590.88 processor : 3 BogoMIPS : 1590.88 Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 2 Hardware : UNIVERSAL5410 Revision : 000a Serial : c90430bd4d00fc18 ----------------------------------------------------------------------- The parameters that I used for valgrind are: VGPARAMS='-v --error-limit=no --tool=memcheck --leak-check=yes --suppressions=/data/local/sup1.supp --suppressions=/data/local/sup2.supp' -- View this message in context: http://valgrind.10908.n7.nabble.com/Valgrind-on-Android-Jelly-Beans-Can-not-launch-app-due-to-unrecognized-instructions-tp47707p53691.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |