When I used valgrind 3.9.0 to trace my program, It reported unhandled instruction 0xEE190F1D. I checked the log and found that unrecognised instruction is at address 0x4ca0368 in /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0. The assembly code corresponding to 0x4ca0368 in libcrypto.so.1.0.0 is: 3a368: 0f1d lsrs r5, r3, #28 Log file: ==2288== Lackey, an example Valgrind tool ==2288== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote. ==2288== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==2288== Command: ./MalStoneB localhost 6000 /testdata/events-malstone-linaro-pandaboard-0.dat ==2288== Parent PID: 1873 ==2288== --2288-- --2288-- Valgrind options: --2288-- --tool=lackey --2288-- -v --2288-- -v --2288-- --log-file=log.txt --2288-- Contents of /proc/version: --2288-- Linux version 3.9.0-1-linaro-omap (root@localhost.localdomain) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) ) #1 SMP Mon Jan 20 16:39:58 UTC 2014 --2288-- Arch and hwcaps: ARM, ARMv7-vfp-neon --2288-- Page sizes: currently 4096, max supported 4096 --2288-- Valgrind library directory: /usr/local/lib/valgrind --2288-- TT/TC: VG_(init_tt_tc) (startup of code management) --2288-- TT/TC: cache: 16 sectors of 8858304 bytes each = 141732864 total --2288-- TT/TC: table: 16 tables of 11531696 bytes each = 184507136 total --2288-- TT/TC: table: 65521 entries each = 1048336 total entries max occupancy 681408 (65%) --2288-- Reading syms from /opt/usb/malstone-googlecode-0_8_2/sector/src/cpp/malstone/malstoneB/MalStoneB --2288-- svma 0x000000b058, avma 0x000000b058 --2288-- Reading syms from /lib/arm-linux-gnueabihf/ld-2.15.so --2288-- svma 0x00000007e0, avma 0x00040007e0 --2288-- Considering /lib/arm-linux-gnueabihf/ld-2.15.so .. --2288-- .. CRC mismatch (computed 202cad9e wanted ad9d7d1a) --2288-- object doesn't have a symbol table --2288-- Reading syms from /usr/local/lib/valgrind/lackey-arm-linux --2288-- svma 0x0038000100, avma 0x0038000100 --2288-- object doesn't have a dynamic symbol table --2288-- Scheduler: using generic scheduler lock implementation. ==2288== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-2288-by-root-on-??? ==2288== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-2288-by-root-on-??? ==2288== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-2288-by-root-on-??? ==2288== ==2288== TO CONTROL THIS PROCESS USING vgdb (which you probably ==2288== don't want to do, unless you know exactly what you're doing, ==2288== or are doing some strange experiment): ==2288== /usr/local/lib/valgrind/../../bin/vgdb --pid=2288 ...command... ==2288== ==2288== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==2288== /path/to/gdb ./MalStoneB ==2288== and then give GDB the following command ==2288== target remote | /usr/local/lib/valgrind/../../bin/vgdb --pid=2288 ==2288== --pid is optional if only one valgrind process is running ==2288== --2288-- TT/TC: initialise sector 0 --2288-- Reading syms from /usr/local/lib/valgrind/vgpreload_core-arm-linux.so --2288-- svma 0x0000000428, avma 0x0004820428 --2288-- Reading syms from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.17 --2288-- svma 0x00000468f0, avma 0x00048718f0 --2288-- Considering /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.17 .. --2288-- .. CRC mismatch (computed 117873cc wanted 7c1359c0) --2288-- object doesn't have a symbol table --2288-- Reading syms from /lib/arm-linux-gnueabihf/libpthread-2.15.so --2288-- svma 0x0000003f30, avma 0x00048d6f30 --2288-- Considering /lib/arm-linux-gnueabihf/libpthread-2.15.so .. --2288-- .. CRC mismatch (computed 873e8465 wanted e287f39d) --2288-- Reading syms from /opt/sector/lib/libclient.so --2288-- svma 0x0000050828, avma 0x000493e828 --2288-- Reading syms from /lib/arm-linux-gnueabihf/libgcc_s.so.1 --2288-- svma 0x000000d1e0, avma 0x00049901e0 --2288-- Considering /lib/arm-linux-gnueabihf/libgcc_s.so.1 .. --2288-- .. CRC mismatch (computed d63fa165 wanted 09e741e7) --2288-- object doesn't have a symbol table --2288-- Reading syms from /lib/arm-linux-gnueabihf/libc-2.15.so --2288-- svma 0x0000015770, avma 0x00049ba770 --2288-- Considering /lib/arm-linux-gnueabihf/libc-2.15.so .. --2288-- .. CRC mismatch (computed 68d48bdd wanted 13730372) --2288-- object doesn't have a symbol table --2288-- Reading syms from /lib/arm-linux-gnueabihf/libm-2.15.so --2288-- svma 0x0000003b98, avma 0x0004a8db98 --2288-- Considering /lib/arm-linux-gnueabihf/libm-2.15.so .. --2288-- .. CRC mismatch (computed 638ebb19 wanted d69b3b57) --2288-- object doesn't have a symbol table --2288-- Reading syms from /opt/sector/lib/libudt.so --2288-- svma 0x000002a788, avma 0x0004b1e788 --2288-- Reading syms from /opt/sector/lib/librpc.so --2288-- svma 0x0000019160, avma 0x0004b6e160 --2288-- Reading syms from /opt/sector/lib/libcommon.so --2288-- svma 0x0000053ef0, avma 0x0004bdaef0 --2288-- Reading syms from /lib/arm-linux-gnueabihf/libssl.so.1.0.0 --2288-- svma 0x000000abc0, avma 0x0004c31bc0 --2288-- Considering /lib/arm-linux-gnueabihf/libssl.so.1.0.0 .. --2288-- .. CRC mismatch (computed d26a0d70 wanted fe728a3d) --2288-- object doesn't have a symbol table --2288-- Reading syms from /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 --2288-- svma 0x0000037fc0, avma 0x0004c9dfc0 --2288-- Considering /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 .. --2288-- .. CRC mismatch (computed f0249849 wanted d635a613) --2288-- object doesn't have a symbol table --2288-- Reading syms from /lib/arm-linux-gnueabihf/libdl-2.15.so --2288-- svma 0x000000093c, avma 0x0004d7193c --2288-- Considering /lib/arm-linux-gnueabihf/libdl-2.15.so .. --2288-- .. CRC mismatch (computed c9ed76e2 wanted d8374434) --2288-- object doesn't have a symbol table --2288-- Reading syms from /lib/arm-linux-gnueabihf/libz.so.1.2.7 --2288-- svma 0x0000001658, avma 0x0004d7d658 --2288-- Considering /lib/arm-linux-gnueabihf/libz.so.1.2.7 .. --2288-- .. CRC mismatch (computed 4218bcee wanted c6a7cf20) --2288-- object doesn't have a symbol table disInstr(arm): unhandled instruction: 0xEE190F1D cond=14(0xE) 27:20=225(0xE1) 4:4=1 3:0=13(0xD) ==2288== valgrind: Unrecognised instruction at address 0x4ca0368. ==2288== at 0x4CA0368: ??? (in /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0) ==2288== Your program just tried to execute an instruction that Valgrind ==2288== did not recognise. There are two possible reasons for this. ==2288== 1. Your program has a bug and erroneously jumped to a non-code ==2288== location. If you are running Memcheck and you just saw a ==2288== warning about a bad jump, it's probably your program's fault. ==2288== 2. The instruction is legitimate but Valgrind doesn't handle it, ==2288== i.e. it's Valgrind's fault. If you think this is the case or ==2288== you are not sure, please let us know and we'll try to fix it. ==2288== Either way, Valgrind will now raise a SIGILL signal which will ==2288== probably kill your program. --2288-- TT/TC: initialise sector 1 --2288-- TT/TC: initialise sector 2 ==2288== ==2288== Counted 0 calls to main() ==2288== ==2288== Jccs: ==2288== total: 7,163,058 ==2288== taken: 2,412,328 ( 33%) ==2288== ==2288== Executed: ==2288== SBs entered: 22,227,392 ==2288== SBs completed: 20,002,486 ==2288== guest instrs: 130,498,786 ==2288== IRStmts: 556,289,799 ==2288== ==2288== Ratios: ==2288== guest instrs : SB entered = 58 : 10 ==2288== IRStmts : SB entered = 250 : 10 ==2288== IRStmts : guest instr = 42 : 10 ==2288== ==2288== Exit code: 0 libcrypto dump file is in the attachment. My Environment: Pandaboard ES Linux 3.9.0-1-linaro-omap #1 SMP Mon Jan 20 16:39:58 UTC 2014 armv7l armv7l armv7l GNU/Linux Reproducible: Always
Created attachment 85176 [details] libcrypto dump file
The assembly code corresponding to 0x4ca0368 in libcrypto.so.1.0.0 is 0x3a368. Please see following code: 3a360: e1fe b.n 3a760 <OBJ_NAME_add+0x48> 3a362: f26e ff1e bl 2a91a2 <_shadow_DES_check_key+0x1a19ee> 3a366: e12f b.n 3a5c8 <OBJ_NAME_new_index+0x30> 3a368: 0f1d lsrs r5, r3, #28 3a36a: ee19 ff1e mrc 15, 0, APSR_nzcv, cr9, cr14, {0} 3a36e: e12f b.n 3a5d0 <OBJ_NAME_new_index+0x38> 3a370: 2f9f cmp r7, #159 ; 0x9f
The valgrind log says it was executing ARM instructions, but the disassembly you quote in comment 2 is Thumb mode. It also looks completely nonsensical (lots of branch-nevers), so I think that you have incorrectly disassembled the code and it is actually ARM mode code. ARM mode 0xEE190F1D is MRC cp15, 0, r0, cr9, cr13, 0 This is trying to read the PMCCNTR, the performance monitor cycle count register.
That would make more sense, since V would be completely unusable if something as basic as lsrs was unimplemented.
It's my program mistake? Any solution can I try? Thanks!
I'm told that the kernel doesn't actually allow userspace access to the PMCCNTR, so any userspace libraries like libcrypto which try to access it are going to have code for "handle SIGILL and fall back to some other source of entropy". So Valgrind could reasonably implement this as "silently pass the SIGILL to the guest binary" I think.
I observer the same on an Odroid U3: disInstr(arm): unhandled instruction: 0xEE190F1D cond=14(0xE) 27:20=225(0xE1) 4:4=1 3:0=13(0xD) ==13064== valgrind: Unrecognised instruction at address 0x4aaa788. ==13064== at 0x4AAA788: ??? (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0) I am running Valgrind-3.9.0.
If the guest binary really does expect to possibly get a SIGILL here and fall back to something else, then the program run under Valgrind should continue successfully after V has printed that message. Does it?
You could try running with --sigill-diagnostics=no. This means it will still whack the program with SIGILL as per comment 8, but not shout about it. So, if you program handles SIGILL, it should continue silently.
*** Bug 328423 has been marked as a duplicate of this bug. ***
Hi, I have the same problem with the latest chrome: disInstr(thumb): unhandled instruction: 0xEE19 0x0F1E ==3037== valgrind: Unrecognised instruction at address 0x87037f. ==3037== at 0x87037E: SpinLock::SlowLock() (in /home/dati/work/blink/src/out/Release/chrome) ==3037== Your program just tried to execute an instruction that Valgrind ==3037== did not recognise. There are two possible reasons for this. ==3037== 1. Your program has a bug and erroneously jumped to a non-code ==3037== location. If you are running Memcheck and you just saw a ==3037== warning about a bad jump, it's probably your program's fault. ==3037== 2. The instruction is legitimate but Valgrind doesn't handle it, ==3037== i.e. it's Valgrind's fault. If you think this is the case or ==3037== you are not sure, please let us know and we'll try to fix it. ==3037== Either way, Valgrind will now raise a SIGILL signal which will ==3037== probably kill your program. ==3037== ==3037== Process terminating with default action of signal 4 (SIGILL) ==3037== Illegal opcode at address 0x87037F ==3037== at 0x87037E: SpinLock::SlowLock() (in /home/dati/work/blink/src/out/Release/chrome) $ arm-linux-gnueabihf-objdump -d chrome | grep "ee19 0f" 7682d8: ee19 0f1e mrc 15, 0, r0, cr9, cr14, {0} 7682e2: ee19 0f3c mrc 15, 0, r0, cr9, cr12, {1} 768322: ee19 0f1d mrc 15, 0, r0, cr9, cr13, {0} 76837e: ee19 0f1e mrc 15, 0, r0, cr9, cr14, {0} 768388: ee19 0f3c mrc 15, 0, r0, cr9, cr12, {1} 7683cc: ee19 0f1d mrc 15, 0, r0, cr9, cr13, {0} 768548: ee19 0f1e mrc 15, 0, r0, cr9, cr14, {0} 768552: ee19 0f3c mrc 15, 0, r0, cr9, cr12, {1} 76866c: ee19 0f1d mrc 15, 0, r0, cr9, cr13, {0} 76869e: ee19 0f1e mrc 15, 0, r0, cr9, cr14, {0} 7686a8: ee19 0f3c mrc 15, 0, r0, cr9, cr12, {1} 7686fa: ee19 0f1d mrc 15, 0, r0, cr9, cr13, {0} 768966: ee19 0f1e mrc 15, 0, r0, cr9, cr14, {0} 768970: ee19 0f3c mrc 15, 0, r0, cr9, cr12, {1} 7689d8: ee19 0f1e mrc 15, 0, r0, cr9, cr14, {0} 7689e2: ee19 0f3c mrc 15, 0, r0, cr9, cr12, {1} 768a3a: ee19 0f1d mrc 15, 0, r0, cr9, cr13, {0} 768a6e: ee19 0f1e mrc 15, 0, r0, cr9, cr14, {0} 768a78: ee19 0f3c mrc 15, 0, r0, cr9, cr12, {1} 768ac4: ee19 0f1d mrc 15, 0, r0, cr9, cr13, {0} 768b58: ee19 0f1d mrc 15, 0, r0, cr9, cr13, {0} 768b8a: ee19 0f1e mrc 15, 0, r0, cr9, cr14, {0} 768b94: ee19 0f3c mrc 15, 0, r0, cr9, cr12, {1} 768be2: ee19 0f1d mrc 15, 0, r0, cr9, cr13, {0}
I experienced this bug on Android 4.4.4 with Valdrind 3.10.1: ==2556== disInstr(arm): unhandled instruction: 0xEE190F1D cond=14(0xE) 27:20=225(0xE1) 4:4=1 3:0=13(0xD) ==2556== valgrind: Unrecognised instruction at address 0x5218d48. ==2556== at 0x5218D48: _fips_armv7_tick (in /system/lib/libcrypto.so) ==2556== Your program just tried to execute an instruction that Valgrind ==2556== did not recognise. There are two possible reasons for this. ==2556== 1. Your program has a bug and erroneously jumped to a non-code ==2556== location. If you are running Memcheck and you just saw a ==2556== warning about a bad jump, it's probably your program's fault. ==2556== 2. The instruction is legitimate but Valgrind doesn't handle it, ==2556== i.e. it's Valgrind's fault. If you think this is the case or ==2556== you are not sure, please let us know and we'll try to fix it. ==2556== Either way, Valgrind will now raise a SIGILL signal which will ==2556== probably kill your program. Disasm for /system/lib/libcrypto.so: 0006ad48 <_fips_armv7_tick>: 6ad48: ee190f1d mrc 15, 0, r0, cr9, cr13, {0} 6ad4c: e12fff1e bx lr 0006ad50 <fips_openssl_atomic_add>: 6ad50: e1902f9f ldrex r2, [r0] 6ad54: e0823001 add r3, r2, r1
I use an evaluation board with a Marvell Armada ARMv7-MP CPU. Compiler: arm-marvell-linux-gnueabi-gcc (Linaro GCC branch-4.6.4. Marvell) valgrind mem-check output: disInstr(arm): unhandled instruction: 0xEE323613 cond=14(0xE) 27:20=227(0xE3) 4:4=1 3:0=3(0x3) ==716== valgrind: Unrecognised instruction at address 0xe2f2c. ... -> causing source code: std::queue<int> Q; Q.size(); -> problematic assembler instruction: e2f2c: ee323613 mrc 6, 1, r3, cr2, cr3, {0} Have someone a patch for this problem?
*** Bug 348536 has been marked as a duplicate of this bug. ***
disInstr(arm): unhandled instruction: 0xEC510F1E cond=14(0xE) 27:20=197(0xC5) 4:4=1 3:0=14(0xE) valgrind: Unrecognised instruction at address 0x4b28948. Your program just tried to execute an instruction that Valgrind did not recognise. There are two possible reasons for this. 1. Your program has a bug and erroneously jumped to a non-code location. If you are running Memcheck and you just saw a warning about a bad jump, it's probably your program's fault. 2. The instruction is legitimate but Valgrind doesn't handle it, i.e. it's Valgrind's fault. If you think this is the case or you are not sure, please let us know and we'll try to fix it. Either way, Valgrind will now raise a SIGILL signal which will probably kill your program. System: ================================================================== Valdrind 3.10.1 Nexus 7 (2013) Android 5.1.1 (Build: LMY47V) Device is rooted, has SuperSU, ADBD Insecure & BusyBox installed, ==================================================================
Verbose output: Valgrind options: -v --xml=yes --error-limit=no --trace-children=yes --tool=memcheck --leak-check=full --show-reachable=yes --xml-file=//storage/sdcard0/testrunner/adsComponentTest/valgrind.xml Contents of /proc/version: Linux version 3.4.0-g0baf67b (android-build@wpiw13.hot.corp.google.com) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #1 SMP PREEMPT Sat Mar 21 03:34:19 UTC 2015 Arch and hwcaps: ARM, LittleEndian, ARMv7-vfp-neon Page sizes: currently 4096, max supported 4096 Valgrind library directory: /data/local/Inst/lib/valgrind Reading syms from /system/bin/sh Considering /system/bin/sh .. .. CRC mismatch (computed 46ee35bb wanted 0c79510e) Reading EXIDX entries: 445 available Reading EXIDX entries: 443 attempted, 443 successful Reading syms from /system/bin/linker Considering /system/bin/linker .. .. CRC mismatch (computed 045d6a91 wanted aea5ba05) Reading syms from /data/local/Inst/lib/valgrind/memcheck-arm-linux Scheduler: using generic scheduler lock implementation. Reading suppressions file: /data/local/Inst/lib/valgrind/default.supp Reading syms from /data/local/Inst/lib/valgrind/vgpreload_core-arm-linux.so [2015-08-13 14:58:57,618 INFO Transport(transport.py/_log_output)]: WARNING: linker: Unsupported flags DT_FLAGS_1=0x421 Reading syms from /data/local/Inst/lib/valgrind/vgpreload_memcheck-arm-linux.so REDIR: 0x4006ed1 (NONE:__dl_strrchr) redirected to 0x481e6b0 (__dl_strrchr) REDIR: 0x4005835 (NONE:__dl_strlen) redirected to 0x481ef4c (__dl_strlen) [2015-08-13 14:58:57,667 INFO Transport(transport.py/_log_output)]: WARNING: linker: Unsupported flags DT_FLAGS_1=0x421 REDIR: 0x4004ed8 (NONE:__dl_strcmp) redirected to 0x48201d0 (__dl_strcmp) Reading syms from /system/lib/libc.so Considering /system/lib/libc.so .. .. CRC mismatch (computed 8b22bdf6 wanted eeee886d) REDIR: 0x483b685 (libc.so:strlen) redirected to 0x481ed8c (strlen) REDIR: 0x4840e69 (libc.so:strchr) redirected to 0x481e6e8 (strchr) REDIR: 0x4860dd5 (libc.so:strncmp) redirected to 0x481f86c (strncmp) Reading syms from /system/lib/libnetd_client.so Considering /system/lib/libnetd_client.so .. .. CRC mismatch (computed 709340c6 wanted 799dfb9f) Reading EXIDX entries: 20 available Reading EXIDX entries: 19 attempted, 19 successful Reading syms from /system/lib/libm.so Considering /system/lib/libm.so .. .. CRC mismatch (computed d1ee496b wanted 5e91d6bd) Reading EXIDX entries: 144 available Reading EXIDX entries: 143 attempted, 140 successful Reading syms from /system/lib/libstdc++.so Considering /system/lib/libstdc++.so .. .. CRC mismatch (computed eb5524a4 wanted 50ecc649) System: ================================================================== Valdrind 3.10.1 Nexus 7 (2013) Android 5.1.1 (Build: LMY47V) Device is rooted, has SuperSU, ADBD Insecure & BusyBox installed, ==================================================================
I'm getting the same crash with the latest valgrid trying to debug ufoai 2.6 on armv7 Odroid C1 SoC: disInstr(thumb): unhandled instruction: 0xEEFE 0x7ACA ==12079== valgrind: Unrecognised instruction at address 0x33fae857. ==12079== at 0x33FAE856: G_VisCheckDist(Edict const*) (g_vis.cpp:169) ==12079== by 0x33FAE8E3: G_Vis(int, Edict const*, Edict const*, unsigned int) (g_vis.cpp:213) ==12079== by 0x33FAEA6D: G_TestVis(int, Edict*, unsigned int) (g_vis.cpp:269) ==12079== by 0x33FAED23: G_DoTestVis (g_vis.cpp:293) ==12079== by 0x33FAED23: G_CheckVisTeam (g_vis.cpp:366) ==12079== by 0x33FAED23: G_CheckVis(Edict*, unsigned int) (g_vis.cpp:416) ==12079== by 0x33F94697: G_SpawnAIPlayer(Player const&, equipDef_s const*) (g_ai.cpp:1889) ==12079== by 0x33F97A91: G_SpawnAIPlayers (g_ai.cpp:1906) ==12079== by 0x33F97A91: AI_CreatePlayer(int) (g_ai.cpp:1977) ==12079== by 0x33FAAF0D: G_SpawnEntities(char const*, bool, char const*) (g_spawn.cpp:384) ==12079== by 0xDBC39: SV_Map(bool, char const*, char const*, bool) (sv_init.cpp:218) ==12079== by 0xDA0E1: SV_Map_f() (sv_ccmds.cpp:181) ==12079== by 0xA2497: Cmd_vExecuteString(char const*, std::__va_list) (cmd.cpp:976) ==12079== by 0xA25B7: Cmd_ExecuteString(char const*, ...) [clone .constprop.30] (cmd.cpp:1012) ==12079== by 0xA277B: Cbuf_Execute() (cmd.cpp:255) while gdb says: Program received signal SIGILL, Illegal instruction. 0x33fae856 in ?? () (gdb) disass 0x33fae856,+1 Dump of assembler code from 0x33fae856 to 0x33fae857: => 0x33fae856: vcvt.s32.f32 s15, s15, #12 Strange that it's still there after all those years ;)
*** This bug has been confirmed by popular vote. ***
(In reply to PeteVine from comment #17) > I'm getting the same crash with the latest valgrid trying to debug ufoai 2.6 > on armv7 Odroid C1 SoC: > Program received signal SIGILL, Illegal instruction. > 0x33fae856 in ?? () > (gdb) disass 0x33fae856,+1 > Dump of assembler code from 0x33fae856 to 0x33fae857: > => 0x33fae856: vcvt.s32.f32 s15, s15, #12 This is completely unrelated, and was fixed earlier today. See #342783.
Nice coincidence, thanks! You should probably move my entries there if it's completely unrelated.
I can also see this bug with running tool=callgrind on a Nexus6. root@shamu:/sdcard # cat callgrind-1.log ==11739== Callgrind, a call-graph generating cache profiler ==11739== Copyright (C) 2002-2015, and GNU GPL'd, by Josef Weidendorfer et al. ==11739== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info ==11739== Command: /system/bin/app_process32_original /system/bin --application --nice-name=com.myapp.profiletest com.android.internal.os.WrapperInit 15 23 android.app.ActivityThread ==11739== Parent PID: 11738 ==11739== ==11739== For interactive control, run 'callgrind_control -h'. disInstr(arm): unhandled instruction: 0xEC510F1E cond=14(0xE) 27:20=197(0xC5) 4:4=1 3:0=14(0xE) ==11739== valgrind: Unrecognised instruction at address 0x4b19948. ==11739== at 0x4B19948: _armv7_tick (in /system/lib/libcrypto.so) ==11739== Your program just tried to execute an instruction that Valgrind ==11739== did not recognise. There are two possible reasons for this. ==11739== 1. Your program has a bug and erroneously jumped to a non-code ==11739== location. If you are running Memcheck and you just saw a ==11739== warning about a bad jump, it's probably your program's fault. ==11739== 2. The instruction is legitimate but Valgrind doesn't handle it, ==11739== i.e. it's Valgrind's fault. If you think this is the case or ==11739== you are not sure, please let us know and we'll try to fix it. ==11739== Either way, Valgrind will now raise a SIGILL signal which will ==11739== probably kill your program.
(In reply to Michael Hess from comment #21) > I can also see this bug with running tool=callgrind on a Nexus6. > > root@shamu:/sdcard # cat callgrind-1.log > > ==11739== Callgrind, a call-graph generating cache profiler > ==11739== Copyright (C) 2002-2015, and GNU GPL'd, by Josef Weidendorfer et > al. > ==11739== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright > info > ==11739== Command: /system/bin/app_process32_original /system/bin > --application --nice-name=com.myapp.profiletest > com.android.internal.os.WrapperInit 15 23 android.app.ActivityThread > ==11739== Parent PID: 11738 > ==11739== > ==11739== For interactive control, run 'callgrind_control -h'. > disInstr(arm): unhandled instruction: 0xEC510F1E > cond=14(0xE) 27:20=197(0xC5) 4:4=1 3:0=14(0xE) > ==11739== valgrind: Unrecognised instruction at address 0x4b19948. > ==11739== at 0x4B19948: _armv7_tick (in /system/lib/libcrypto.so) > ==11739== Your program just tried to execute an instruction that Valgrind > ==11739== did not recognise. There are two possible reasons for this. > ==11739== 1. Your program has a bug and erroneously jumped to a non-code > ==11739== location. If you are running Memcheck and you just saw a > ==11739== warning about a bad jump, it's probably your program's fault. > ==11739== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==11739== i.e. it's Valgrind's fault. If you think this is the case or > ==11739== you are not sure, please let us know and we'll try to fix it. > ==11739== Either way, Valgrind will now raise a SIGILL signal which will > ==11739== probably kill your program. Yo can safely ignore the error. Libcrypto.so does a SIGILL on purpose. use: "valgrind --sigill-diagnostics=no ..."
I've managed to get the right one as well :) Program received signal SIGILL, Illegal instruction. 0x048ef208 in ?? () from /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 (gdb) bt #0 0x048ef208 in ?? () from /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 #1 0x048eceb0 in OPENSSL_cpuid_setup () from /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 #2 0x0400b20e in call_init (l=<optimized out>, argc=3, argv=0xbdf5df14, env=0xbdf5df24) at dl-init.c:78 #3 0x0400b2a0 in _dl_init (main_map=0x4020958, argc=3, argv=0xbdf5df14, env=0xbdf5df24) at dl-init.c:126 #4 0x04000bf2 in _dl_start_user () from /lib/ld-linux-armhf.so.3 (gdb) disassemble 0x048ef208,+1 Dump of assembler code from 0x48ef208 to 0x48ef209: => 0x048ef208: mrc 15, 0, r0, cr9, cr13, {0}
I'm having this issue with libcrypto on a raspberry pi, but my unhandled instruction is 0xEC510F1E . cond=14(0xE) 27:20=197(0xC5) 4:4=1 3:0=14(0xE) at 0x4907728 in /usr/lib/arm-linux/gnueabihf/libcrypto.so.1.1 The SIGILL is silently absorbed.