--70318-- WARNING: unhandled syscall: 216 --70318-- You may be able to write your own handler. --70318-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --70318-- Nevertheless we consider this a bug. Please report --70318-- it at http://valgrind.org/support/bug_reports.html. --70318-- WARNING: unhandled syscall: 216 --70318-- You may be able to write your own handler. --70318-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --70318-- Nevertheless we consider this a bug. Please report --70318-- it at http://valgrind.org/support/bug_reports.html. vex amd64->IR: unhandled instruction bytes: 0x48 0x8C 0xDB 0x48 0x89 0x98 0xB8 0x0 vex amd64->IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==70318== valgrind: Unrecognised instruction at address 0xd1379f0. Reproducible: Always Steps to Reproduce: 1. start up the process under valgrind with the following options: valgrind --tool=drd --gen-suppressions=yes --shared-threshold=10 --exclusive-threshold=10 --error-limit=no 2. process aborts 3. Actual Results: Can be reproduced only on our system. The problem only occurs when the process is run under valgrind. Expected Results: The process should successfully execute system call and continue to run. That's what happens when it runs without valgrind.
Two apparently unrelated things happened here. First, syscall 216 was pre-failed by Valgrind, since it isn't currently supported. But that doesn't kill the process. Secondly, some time later, the process ran into an unimplemented instruction. What does your app do when 216 fails? Does it assume it always succeeds? You could try with -v --trace-signals=yes to see if you can get a stack trace at the point where the unimplemented insn happens.
Instruction is MOV r/m64,Sreg which is "Move zero extended 16-bit segment register to r/m64" and so distinctly at the odd end of the spectrum.
Thanks for your answer. The resulting crash from unimplemented instruction was caused by remap_file_pages call not executed. That's what I was able to diagnose. The failing program needs a lot of surrounding infrastructure without which it's impossible to run it. Essentially, the program heavily relies on memory mapping and remapping to implement some mechanism. I can compile and run with this mechanism disabled but then it defies the whole purpose of using Valgrind to diagnose mutex contention. I wrote a simple program to illustrate the problem, but I guess, you are already aware of it. Input file created: dd if=/dev/zero of=input bs=4kB count=16 Until support for this call is added I can use Valgrind in limited mode to diagnose various issues. #include <sys/types.h> #include <sys/stat.h> #include <sys/mman.h> #include <fcntl.h> #include <unistd.h> #include <stdlib.h> #include <stdio.h> #include <string.h> int main(int argc, char **argv) { char buf[1024]; void *base; int fd; size_t pagesz = sysconf(_SC_PAGE_SIZE); if ( argc < 2 ) { fprintf(stderr, "Missing file\n"); return 1; } printf("Opening file %s\n", argv[1]); fd = open(argv[1], O_RDWR); if (fd < 0) { perror("open"); return 1; } base = mmap(0, 4*pagesz, PROT_READ, MAP_SHARED, fd, 0); if (base < 0) { perror("mmap"); close(fd); return 1; } memcpy(buf, (char*)base + 2*pagesz, 1024); if (remap_file_pages(base, pagesz, 0, 2, 0) < 0) { perror("remap_file_pages"); munmap(base, 4*pagesz); close(fd); return 1; } printf("After remap_file_pages %d\n", memcmp(buf, base, 1024)); munmap(base, 4*pagesz); close(fd); printf("Before returing from main\n"); return 0; }
*** This bug has been marked as a duplicate of bug 309554 ***