I have an ARMv6 Raspberry Pi that I'm compiling and testing a small TCP server on. I'm using the epoll system call in my c/c++ program. The program runs fine when I don't use valgrind. However, when I use valgrind, the call to 'epoll_wait' returns -1, which indicates a kernel level error. This doesn't happen with valgrind and the same program on my typical desktop with an intel i7 cpu. See the results of valgrind below. ==2615== Memcheck, a memory error detector ==2615== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==2615== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==2615== Command: ./src/app/bserver ==2615== --2615-- WARNING: unhandled syscall: 357 --2615-- You may be able to write your own handler. --2615-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --2615-- Nevertheless we consider this a bug. Please report --2615-- it at http://valgrind.org/support/bug_reports.html. --2615-- WARNING: unhandled syscall: 357 --2615-- You may be able to write your own handler. --2615-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --2615-- Nevertheless we consider this a bug. Please report --2615-- it at http://valgrind.org/support/bug_reports.html. disInstr(arm): unhandled instruction: 0xF1010200 cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0) ==2615== valgrind: Unrecognised instruction at address 0x4842588. ==2615== at 0x4842588: ??? (in /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so) ==2615== Your program just tried to execute an instruction that Valgrind ==2615== did not recognise. There are two possible reasons for this. ==2615== 1. Your program has a bug and erroneously jumped to a non-code ==2615== location. If you are running Memcheck and you just saw a ==2615== warning about a bad jump, it's probably your program's fault. ==2615== 2. The instruction is legitimate but Valgrind doesn't handle it, ==2615== i.e. it's Valgrind's fault. If you think this is the case or ==2615== you are not sure, please let us know and we'll try to fix it. ==2615== Either way, Valgrind will now raise a SIGILL signal which will ==2615== probably kill your program. ==2615== ==2615== Process terminating with default action of signal 4 (SIGILL) ==2615== Illegal opcode at address 0x4842588 ==2615== at 0x4842588: ??? (in /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so) ==2615== ==2615== HEAP SUMMARY: ==2615== in use at exit: 44,142 bytes in 302 blocks ==2615== total heap usage: 347 allocs, 45 frees, 48,218 bytes allocated ==2615== ==2615== LEAK SUMMARY: ==2615== definitely lost: 0 bytes in 0 blocks ==2615== indirectly lost: 0 bytes in 0 blocks ==2615== possibly lost: 3,060 bytes in 87 blocks ==2615== still reachable: 41,082 bytes in 215 blocks ==2615== suppressed: 0 bytes in 0 blocks ==2615== Rerun with --leak-check=full to see details of leaked memory ==2615== ==2615== For counts of detected and suppressed errors, rerun with: -v ==2615== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Killed
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 ***