On Fri, Aug 27, 2021 at 2:47 PM Ken Goldman <kgoldman@xxxxxxxxxx> wrote: > > I run valgrind on all my software to find memory leaks. This worked for > openssl 1.0.2 and 1.1.1, but fails with 3.0.0. Suggestions? > > vex amd64->IR: unhandled instruction bytes: 0xF3 0xF 0x1E 0xFA 0x49 0x89 0xD8 0x31 > 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=0F > vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=1 > ==29625== valgrind: Unrecognised instruction at address 0x56b2b10. > ==29625== at 0x56B2B10: OPENSSL_ia32_cpuid (x86_64cpuid.s:36) > ==29625== by 0x569FA37: OPENSSL_cpuid_setup (cpuid.c:147) > ==29625== by 0x55163C2: ??? (in /home/kgold/openssl30/libcrypto.so.3) > ==29625== Your program just tried to execute an instruction that Valgrind > ==29625== did not recognise. There are two possible reasons for this. > ==29625== 1. Your program has a bug and erroneously jumped to a non-code > ==29625== location. If you are running Memcheck and you just saw a > ==29625== warning about a bad jump, it's probably your program's fault. > ==29625== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==29625== i.e. it's Valgrind's fault. If you think this is the case or > ==29625== you are not sure, please let us know and we'll try to fix it. > ==29625== Either way, Valgrind will now raise a SIGILL signal which will > ==29625== probably kill your program. > ==29625== > ==29625== Process terminating with default action of signal 4 (SIGILL) > ==29625== Illegal opcode at address 0x56B2B10 > ==29625== at 0x56B2B10: OPENSSL_ia32_cpuid (x86_64cpuid.s:36) > ==29625== by 0x569FA37: OPENSSL_cpuid_setup (cpuid.c:147) > ==29625== by 0x55163C2: ??? (in /home/kgold/openssl30/libcrypto.so.3) > I stopped using valgrind awhile ago, because I had too many issues with false positives, etc. I really noticed this when dealing with glib/dbus. At this time, I made the switch to ASAN and both gcc and clang support it and the diagnostics have been better than anything I got with valgrind; it's been many years and I never looked back. Just google your compiler and asan and you should get guides, but in general it's as easy as adding CFLAGS='-O0 -g -fsanitize=address -fno-omit-frame-pointer' Then just run the binary as normal. You may need to set up the symbolizer to resolve addresses to file/line names. IIRC its via the ASAN_SYMBOLIZER_PATH and that is discussed further in the ASAN docs. I would give that a try, that's what I am using for OpenSSL 3.0 integration and fuzzing in my CI's Bill
