When running Valgrind against one of our C libraries we encountered some discrepancies in the build where locally all would pass but on AWS CodeBuild using the aws/codebuild/standard:2.0 image we would get errors like:
vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7D 0x48 0xEF 0xC0 0xC5 0xF9 0x2E 0x45
The full message was like:
==16128== Memcheck, a memory error detector ==16128== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==16128== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==16128== Command: /root/build/meh/test/.libs/state ==16128== [==========] Running 2 test(s). [ RUN ] test1 vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7D 0x48 0xEF 0xC0 0xC5 0xF9 0x2E 0x45 vex amd64->IR: REX=0 REX.W=0 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 ==16128== valgrind: Unrecognised instruction at address 0x1173bd. =... ==16128== Your program just tried to execute an instruction that Valgrind ==16128== did not recognise. There are two possible reasons for this. ==16128== 1. Your program has a bug and erroneously jumped to a non-code ==16128== location. If you are running Memcheck and you just saw a ==16128== warning about a bad jump, it's probably your program's fault. ==16128== 2. The instruction is legitimate but Valgrind doesn't handle it, ==16128== i.e. it's Valgrind's fault. If you think this is the case or ==16128== you are not sure, please let us know and we'll try to fix it. ==16128== Either way, Valgrind will now raise a SIGILL signal which will ==16128== probably kill your program.
The error seems to indicate that the architecture doesn’t seem to match what the docker image had so going off of a Linux Headers Reinstall article we added the following and then the architecture packages were fine.
apt upgrade --fix-missing -y && apt autoremove -y && apt autoclean -y