Summary: | ARM: disInstr(arm): unhandled instruction: 0xF1010200 | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | alexander.ressler |
Component: | memcheck | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | CC: | ivosh, mark, noloader, tom, Werner.Frick |
Priority: | NOR | ||
Version: | 3.7.0 | ||
Target Milestone: | --- | ||
Platform: | Debian stable | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | valgrind.log |
Description
alexander.ressler
2016-01-27 05:41:37 UTC
This is epoll_create1. Yes, it's epol_create1. This is with 3.7.0, which is really old now. Can you try again with 3.11.0 or better with the current SVN trunk? > This is with 3.7.0, which is really old now. Can you try again with 3.11.0 or better with the current SVN trunk? The issue is present when building 3.11 from sources: raspberrypi:botan$ valgrind ./botan-test ==6661== Memcheck, a memory error detector ==6661== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==6661== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==6661== Command: ./botan-test ==6661== disInstr(arm): unhandled instruction: 0xF1010200 cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0) ==6661== valgrind: Unrecognised instruction at address 0x486b6f4. ==6661== at 0x486B6F4: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so) ==6661== Your program just tried to execute an instruction that Valgrind ==6661== did not recognise. There are two possible reasons for this. ==6661== 1. Your program has a bug and erroneously jumped to a non-code ==6661== location. If you are running Memcheck and you just saw a ==6661== warning about a bad jump, it's probably your program's fault. ==6661== 2. The instruction is legitimate but Valgrind doesn't handle it, ==6661== i.e. it's Valgrind's fault. If you think this is the case or ==6661== you are not sure, please let us know and we'll try to fix it. ==6661== Either way, Valgrind will now raise a SIGILL signal which will ==6661== probably kill your program. ==6661== ==6661== Process terminating with default action of signal 4 (SIGILL) ==6661== Illegal opcode at address 0x486B6F4 ==6661== at 0x486B6F4: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so) It looks like the issue affects a lot of folks: http://www.google.com/search?q="unhandled+instruction%3A+0xF1010200" > This is with 3.7.0, which is really old now. Can you try again with 3.11.0 or better with the current SVN trunk?
It is still present in the trunk.
raspberrypi:botan$ valgrind ./botan-test
==22114== Memcheck, a memory error detector
==22114== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==22114== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==22114== Command: ./botan-test
==22114==
disInstr(arm): unhandled instruction: 0xF1010200
cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0)
==22114== valgrind: Unrecognised instruction at address 0x486b6f4.
...
And:
$ svn info -r HEAD
Path: trunk
URL: svn://svn.valgrind.org/valgrind/trunk
Relative URL: ^/trunk
Repository Root: svn://svn.valgrind.org/valgrind
Repository UUID: a5019735-40e9-0310-863c-91ae7b9d1cf9
Revision: 15920
Node Kind: directory
Last Changed Author: iraisr
Last Changed Rev: 15920
Last Changed Date: 2016-07-29 23:04:20 -0400 (Fri, 29 Jul 2016)
This may matter: $ echo $CFLAGS -DNDEBUG -g2 -O3 -march=armv8-a+crc -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard $ echo $CXXFLAGS -DNDEBUG -g2 -O3 -march=armv8-a+crc -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard Th device is a Raspberry Pi 3. Its an ARMv8 device with a Broadcom SoC based on A53 cores. It ships with a 32-bit OS named Raspbian, which effectively makes it Aarch32. The Broadcom SoC has ASIMD (v8 NEON) and CRC32, but it lacks Crypto extensions. That explains the unusual CFLAGS and CXXFLAGS. epoll_create1 is now supported by the trunk, at least, so we can cross that off the list of breakage here. (In reply to Jeffrey Walton from comment #6) Jeffrey, can you please objdump -d the relevant .so and find the failing instruction? And/or try again with the trunk? A bunch of 32 bit ARMv8 insns got fixed recently and some more are due to get fixed shortly. Created attachment 103750 [details]
valgrind.log
Hi, I have a very similar problem (though not wite the same). I am using Valgrind 3.12.0 on a Raspberry. According Julian's comment, many of these things should have been fixed. My program does have memory leaks but runs ok for a few days. With Valgrind it exits immediately (see attachment valgrind.log). Any idea? I've done some googling for you as regards "unhandled instruction: 0xF1010200" and found this bug: https://bugs.kde.org/show_bug.cgi?id=322935 See https://bugs.kde.org/show_bug.cgi?id=322935#c27 and the comments that follow. *** This bug has been marked as a duplicate of bug 322935 *** |