Created attachment 123851 [details] valgrind log file and sample source code SUMMARY When valgrind is used on an application with hdf5, an "unhandled instruction bytes" error is displayed (cf vg_log.txt) STEPS TO REPRODUCE 1. compile sample program with hdf5: g++ -g h5simple.cpp -lhdf5 -o h5s_9.2.0 2. run it with valgrind valgrind -v --log-file=vg_log.txt ./h5s_9.2.0 OBSERVED RESULT Valgrind halts execution with "unhandled instruction bytes" message. EXPECTED RESULT "Normal" valgrind mem-check operation SOFTWARE/OS VERSIONS Linux aim-frog 4.19.66-gentoo #1 SMP Mon Sep 9 09:32:22 -00 2019 x86_64 Intel(R) Xeon(R) W-2195 CPU @ 2.30GHz GenuineIntel GNU/Linux ADDITIONAL INFORMATION Outside of valgrind the application runs without errors. I could reproduce the error with valgrind versions 3.13.0, 3.14.0, 3.15.0. It is independent of the compiler i used (gcc 6.4.0,7.4.0,8.3.0,9.2.0) The version of hdf5 is 1.10.5
Here's the actual detail extracted from the attached log: vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFE 0x8 0x6F 0x45 0x0 0xC5 0xF8 0x11 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 ==35078== valgrind: Unrecognised instruction at address 0x4a50820. ==35078== at 0x4A50820: H5P_dup_prop (in /usr/lib64/libhdf5.so.103.1.0) ==35078== by 0x4A52465: H5P__do_prop_cb1.part.13 (in /usr/lib64/libhdf5.so.103.1.0) ==35078== by 0x4A51C01: H5P_create_id (in /usr/lib64/libhdf5.so.103.1.0) ==35078== by 0x4A52155: H5P__init_package (in /usr/lib64/libhdf5.so.103.1.0) ==35078== by 0x4A522C7: H5P_init (in /usr/lib64/libhdf5.so.103.1.0) ==35078== by 0x48C60ED: H5_init_library (in /usr/lib64/libhdf5.so.103.1.0) ==35078== by 0x48C690F: H5open (in /usr/lib64/libhdf5.so.103.1.0) ==35078== by 0x1091C8: main (h5simple.cpp:6)
*** 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.