SUMMARY I tried to use Valgrind's memcheck tool to analyze lepton, source code address: https://github.com/dropbox/lepton STEPS TO REPRODUCE 1. Download source code of lepton 2. Compile 3. valgrind ./lepton sample.jpg ./test.lep OBSERVED RESULT The output of Valgrind with -v flag: ==22039== Memcheck, a memory error detector ==22039== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==22039== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==22039== Command: ./lepton ../../images/hq.jpg ./test.lep ==22039== Parent PID: 26154 ==22039== --22039-- --22039-- Valgrind options: --22039-- --log-file=valgrind.error.log --22039-- -v --22039-- Contents of /proc/version: --22039-- Linux version 4.18.0-25-generic (buildd@lcy01-amd64-025) (gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1~18.10.1)) #26-Ubuntu SMP Mon Jun 24 09:32:08 UTC 2019 --22039-- --22039-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi --22039-- Page sizes: currently 4096, max supported 4096 --22039-- Valgrind library directory: /usr/lib/valgrind --22039-- Reading syms from /home/bwang/Bowen/gitrepo/aflpp-target/lepton/lepton-vanilla/install/bin/lepton --22039-- Reading syms from /lib/x86_64-linux-gnu/ld-2.28.so --22039-- Considering /lib/x86_64-linux-gnu/ld-2.28.so .. --22039-- .. CRC mismatch (computed 5ec4c3b2 wanted 81437a46) --22039-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.28.so .. --22039-- .. CRC is valid --22039-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux --22039-- Considering /usr/lib/valgrind/memcheck-amd64-linux .. --22039-- .. CRC mismatch (computed 7d55ff08 wanted 5bd5b496) --22039-- object doesn't have a symbol table --22039-- object doesn't have a dynamic symbol table --22039-- Scheduler: using generic scheduler lock implementation. --22039-- Reading suppressions file: /usr/lib/valgrind/default.supp ==22039== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-22039-by-bwang-on-??? ==22039== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-22039-by-bwang-on-??? ==22039== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-22039-by-bwang-on-??? ==22039== ==22039== TO CONTROL THIS PROCESS USING vgdb (which you probably ==22039== don't want to do, unless you know exactly what you're doing, ==22039== or are doing some strange experiment): ==22039== /usr/lib/valgrind/../../bin/vgdb --pid=22039 ...command... ==22039== ==22039== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==22039== /path/to/gdb ./lepton ==22039== and then give GDB the following command ==22039== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=22039 ==22039== --pid is optional if only one valgrind process is running ==22039== --22039-- REDIR: 0x40203c0 (ld-linux-x86-64.so.2:strlen) redirected to 0x5805a041 (???) --22039-- REDIR: 0x40201a0 (ld-linux-x86-64.so.2:index) redirected to 0x5805a05b (???) --22039-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so --22039-- Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so .. --22039-- .. CRC mismatch (computed df1b7509 wanted fd78710c) --22039-- object doesn't have a symbol table --22039-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so --22039-- Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so .. --22039-- .. CRC mismatch (computed 4ed40f91 wanted 9c0db13a) --22039-- object doesn't have a symbol table ==22039== WARNING: new redirection conflicts with existing -- ignoring it --22039-- old: 0x040203c0 (strlen ) R-> (0000.0) 0x5805a041 ??? --22039-- new: 0x040203c0 (strlen ) R-> (2007.0) 0x0483a970 strlen --22039-- REDIR: 0x401cbe0 (ld-linux-x86-64.so.2:strcmp) redirected to 0x483ba30 (strcmp) --22039-- REDIR: 0x4020900 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x483edf0 (mempcpy) --22039-- Reading syms from /lib/x86_64-linux-gnu/libpthread-2.28.so --22039-- Considering /usr/lib/debug/.build-id/d7/ce1c3b1a3169d65c31021947a9778ae91bf8a0.debug .. --22039-- .. build-id is valid --22039-- Reading syms from /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25 --22039-- object doesn't have a symbol table --22039-- Reading syms from /lib/x86_64-linux-gnu/libm-2.28.so --22039-- Considering /lib/x86_64-linux-gnu/libm-2.28.so .. --22039-- .. CRC mismatch (computed 529e14fd wanted 48e8513d) --22039-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.28.so .. --22039-- .. CRC is valid --22039-- Reading syms from /lib/x86_64-linux-gnu/libc-2.28.so --22039-- Considering /lib/x86_64-linux-gnu/libc-2.28.so .. --22039-- .. CRC mismatch (computed f813393c wanted b5a550c8) --22039-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.28.so .. --22039-- .. CRC is valid --22039-- Reading syms from /lib/x86_64-linux-gnu/libgcc_s.so.1 --22039-- object doesn't have a symbol table --22039-- REDIR: 0x4c4b230 (libc.so.6:memmove) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4a430 (libc.so.6:strncpy) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4b510 (libc.so.6:strcasecmp) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c49e60 (libc.so.6:strcat) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4a460 (libc.so.6:rindex) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4cc80 (libc.so.6:rawmemchr) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c67c70 (libc.so.6:wcscmp) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4b3a0 (libc.so.6:mempcpy) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4b1d0 (libc.so.6:bcmp) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4a3d0 (libc.so.6:strncmp) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c49ed0 (libc.so.6:strcmp) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4b300 (libc.so.6:memset) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c67c40 (libc.so.6:wcschr) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4a370 (libc.so.6:strnlen) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c49f60 (libc.so.6:strcspn) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4b560 (libc.so.6:strncasecmp) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c49f30 (libc.so.6:strcpy) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4b6a0 (libc.so.6:memcpy@@GLIBC_2.14) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4a490 (libc.so.6:strpbrk) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c49e90 (libc.so.6:index) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4a340 (libc.so.6:strlen) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c54190 (libc.so.6:memrchr) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4b5b0 (libc.so.6:strcasecmp_l) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4b1a0 (libc.so.6:memchr) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c67d50 (libc.so.6:wcslen) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4a730 (libc.so.6:strspn) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4b4e0 (libc.so.6:stpncpy) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4b4b0 (libc.so.6:stpcpy) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4ccb0 (libc.so.6:strchrnul) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4b600 (libc.so.6:strncasecmp_l) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4c4b0e0 (libc.so.6:strstr) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4cda4b0 (libc.so.6:__memmove_chk) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) --22039-- REDIR: 0x4cda3e0 (libc.so.6:__memcpy_chk) redirected to 0x482d1b0 (_vgnU_ifunc_wrapper) ==22039== WARNING: new redirection conflicts with existing -- ignoring it --22039-- old: 0x04d34430 (__memcpy_chk_avx_una) R-> (2024.0) 0x0483e8b0 __memmove_chk --22039-- new: 0x04d34430 (__memcpy_chk_avx_una) R-> (2030.0) 0x0483eee0 __memcpy_chk --22039-- REDIR: 0x4d33d30 (libc.so.6:__strrchr_avx2) redirected to 0x483a380 (rindex) --22039-- REDIR: 0x4c45b90 (libc.so.6:malloc) redirected to 0x48376e0 (malloc) --22039-- REDIR: 0x4d33f00 (libc.so.6:__strlen_avx2) redirected to 0x483a850 (strlen) --22039-- REDIR: 0x4d30510 (libc.so.6:__memcmp_avx2_movbe) redirected to 0x483d770 (bcmp) --22039-- REDIR: 0x4d2f440 (libc.so.6:__strcmp_avx2) redirected to 0x483b8f0 (strcmp) --22039-- REDIR: 0x4d2f880 (libc.so.6:__strncmp_avx2) redirected to 0x483b000 (strncmp) --22039-- REDIR: 0x4c4ac60 (libc.so.6:__GI_strstr) redirected to 0x483f050 (__strstr_sse2) --22039-- REDIR: 0x4c47b20 (libc.so.6:posix_memalign) redirected to 0x4839bd0 (posix_memalign) --22039-- REDIR: 0x4d348c0 (libc.so.6:__memset_avx2_unaligned_erms) redirected to 0x483dea0 (memset) --22039-- REDIR: 0x4d30060 (libc.so.6:__rawmemchr_avx2) redirected to 0x483e950 (rawmemchr) --22039-- REDIR: 0x4d33b40 (libc.so.6:__strchrnul_avx2) redirected to 0x483e920 (strchrnul) vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7E 0x28 0x7F 0x5 0xC6 0xEA 0x12 0x0 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 ==22039== valgrind: Unrecognised instruction at address 0x124878. ==22039== at 0x124878: reset_buffers() (jpgcoder.cc:4402) ==22039== by 0x126A47: app_main(int, char**) (jpgcoder.cc:920) ==22039== by 0x4BD409A: (below main) (libc-start.c:308) ==22039== Your program just tried to execute an instruction that Valgrind ==22039== did not recognise. There are two possible reasons for this. ==22039== 1. Your program has a bug and erroneously jumped to a non-code ==22039== location. If you are running Memcheck and you just saw a ==22039== warning about a bad jump, it's probably your program's fault. ==22039== 2. The instruction is legitimate but Valgrind doesn't handle it, ==22039== i.e. it's Valgrind's fault. If you think this is the case or ==22039== you are not sure, please let us know and we'll try to fix it. ==22039== Either way, Valgrind will now raise a SIGILL signal which will ==22039== probably kill your program. ==22039== ==22039== Process terminating with default action of signal 4 (SIGILL) ==22039== Illegal opcode at address 0x124878 ==22039== at 0x124878: reset_buffers() (jpgcoder.cc:4402) ==22039== by 0x126A47: app_main(int, char**) (jpgcoder.cc:920) ==22039== by 0x4BD409A: (below main) (libc-start.c:308) --22039-- REDIR: 0x4c46310 (libc.so.6:free) redirected to 0x4838910 (free) ==22039== ==22039== HEAP SUMMARY: ==22039== in use at exit: 24 bytes in 1 blocks ==22039== total heap usage: 2 allocs, 1 frees, 72,728 bytes allocated ==22039== ==22039== Searching for pointers to 1 not-freed blocks ==22039== Checked 620,328 bytes ==22039== ==22039== LEAK SUMMARY: ==22039== definitely lost: 0 bytes in 0 blocks ==22039== indirectly lost: 0 bytes in 0 blocks ==22039== possibly lost: 0 bytes in 0 blocks ==22039== still reachable: 24 bytes in 1 blocks ==22039== suppressed: 0 bytes in 0 blocks ==22039== Rerun with --leak-check=full to see details of leaked memory ==22039== ==22039== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==22039== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Output of uname -a: Linux UNIX 4.18.0-25-generic #26-Ubuntu SMP Mon Jun 24 09:32:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
*** This bug has been marked as a duplicate of bug 393351 ***
This bug has been reported 5 times in the past year, as bug numbers 393351, 409999, 414944, 411303 and 414053. I would like to fix it. I tried the steps-to-reproduce shown in bugs 393351 and 414053, but without success: I can't reproduce it either with the trunk or with 3.15.0. Without being able to reproduce it, I can't fix it. The first unhandled byte, 0x62, isn't the start of any known instruction (in 64-bit mode), so I suspect there has been some failure earlier on. Maybe Valgrind's instruction decoder lost track of where it was on the previous instruction. That's just a guess, though. What would be really helpful is if someone could reproduce the failure, and then use objdump -d to show the instructions around the failure point. I can give guidance on how to use objdump if that helps. If you want to try this, I suggest you first reproduce the failure while giving --demangle=no --sym-offsets=yes to Valgrind. That will make it much easier to relate the stack trace that Valgrind produces at the failure point, to the output of objdump -d.