|
From: Jim S. <ji...@ji...> - 2016-01-09 22:35:12
|
Running Ubuntu/Mate on a Raspberry Pi 2, I get the following error:
disInstr(arm): unhandled instruction: 0xF1010200
cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0)
==2462== valgrind: Unrecognised instruction at address 0x48596f4.
==2462== at 0x48596F4: ??? (in
/usr/lib/arm-linux-gnueabihf/libarmmem.so)
==2462== Your program just tried to execute an instruction that Valgrind
==2462== did not recognise. There are two possible reasons for this.
==2462== 1. Your program has a bug and erroneously jumped to a non-code
==2462== location. If you are running Memcheck and you just saw a
==2462== warning about a bad jump, it's probably your program's
fault.
==2462== 2. The instruction is legitimate but Valgrind doesn't
handle it,
==2462== i.e. it's Valgrind's fault. If you think this is the
case or
==2462== you are not sure, please let us know and we'll try to
fix it.
==2462== Either way, Valgrind will now raise a SIGILL signal which will
==2462== probably kill your program.
==2462==
==2462== Process terminating with default action of signal 4 (SIGILL)
==2462== Illegal opcode at address 0x48596F4
==2462== at 0x48596F4: ??? (in
/usr/lib/arm-linux-gnueabihf/libarmmem.so)
==2462==
Any clue(s) would be appreciated.
|
|
From: Jeffrey W. <nol...@gm...> - 2016-01-09 23:45:40
|
On Sat, Jan 9, 2016 at 5:34 PM, Jim Starkey <ji...@ji...> wrote: > Running Ubuntu/Mate on a Raspberry Pi 2, I get the following error: > > disInstr(arm): unhandled instruction: 0xF1010200 > cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0) > ==2462== valgrind: Unrecognised instruction at address 0x48596f4. > ==2462== at 0x48596F4: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so) > ==2462== Your program just tried to execute an instruction that Valgrind > ==2462== did not recognise. There are two possible reasons for this. > ==2462== 1. Your program has a bug and erroneously jumped to a non-code > ==2462== location. If you are running Memcheck and you just saw a > ==2462== warning about a bad jump, it's probably your program's fault. > ==2462== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==2462== i.e. it's Valgrind's fault. If you think this is the case or > ==2462== you are not sure, please let us know and we'll try to fix it. > ==2462== Either way, Valgrind will now raise a SIGILL signal which will > ==2462== probably kill your program. > ==2462== > ==2462== Process terminating with default action of signal 4 (SIGILL) > ==2462== Illegal opcode at address 0x48596F4 > ==2462== at 0x48596F4: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so) > ==2462== > > Any clue(s) would be appreciated. I'm *guessing* you are using a downlevel Valgrind package like debian-3.10.1-... You need Valgrind 3.11 for the most complete ARM/ARM64 support. Here's a Debian package that produced a similar finding on me earlier today with a LeMaker HiKey (http://www.amazon.com/dp/B019O3QTSA): # apt-cache show valgrind Package: valgrind Version: 1:3.10.0-4 Installed-Size: 49816 Maintainer: Alessandro Ghedini <gh...@de...> Architecture: arm64 Replaces: valgrind-dev ... Jeff |
|
From: Tom H. <to...@co...> - 2016-01-10 00:12:02
|
On 09/01/16 22:34, Jim Starkey wrote: > Running Ubuntu/Mate on a Raspberry Pi 2, I get the following error: > > disInstr(arm): unhandled instruction: 0xF1010200 > cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0) See https://bugs.kde.org/show_bug.cgi?id=322935 but the short version is that the code has an insane "optimisation" that temporarily changes the endianism of the processor and there's no way it's ever likely to be supported in valgrind. I believe, from a brief examination when somebody hit this the other day, that libarmmem is just optimised version of some routines like memcpy that are already in the normal C library, so you can just drop it and use the normal C library versions when valgrinding. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Jim S. <ji...@ji...> - 2016-01-12 16:45:56
|
On 1/9/2016 7:11 PM, Tom Hughes wrote: > On 09/01/16 22:34, Jim Starkey wrote: > >> Running Ubuntu/Mate on a Raspberry Pi 2, I get the following error: >> >> disInstr(arm): unhandled instruction: 0xF1010200 >> cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0) > > See https://bugs.kde.org/show_bug.cgi?id=322935 but the short version > is that the code has an insane "optimisation" that temporarily changes > the endianism of the processor and there's no way it's ever likely to > be supported in valgrind. > > I believe, from a brief examination when somebody hit this the other > day, that libarmmem is just optimised version of some routines like > memcpy that are already in the normal C library, so you can just drop > it and use the normal C library versions when valgrinding. > I appreciate the response. It wasn't what I was hoping for, of course, but it beats spending a couple of days bashing my head against the wall. Thanks. |