Summary: | disInstr(arm): unhandled instruction: 0xEE190F1D | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | hujianan |
Component: | general | Assignee: | Julian Seward <jseward> |
Status: | CONFIRMED --- | ||
Severity: | critical | CC: | 0xloem, balaret, d.ansorregui, daajjall, dati91, g3777008, joe.liccese, khushalani.sagar, mhess, peter.maydell, steve.rich.dev |
Priority: | NOR | ||
Version: | 3.9.0 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Other | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | libcrypto dump file |
Description
hujianan
2014-02-16 10:16:36 UTC
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. |