https://bugs.kde.org/show_bug.cgi?id=393351
--- Comment #15 from jody <jody....@gmail.com> --- Hi Julian I can still reproduce the failure. When i run valgrind with '--demangle=no --sym-offsets=yes' i get a stack dump as follows: ----- 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 ==6297== valgrind: Unrecognised instruction at address 0x4a54820. ==6297== at 0x4A54820: H5P_dup_prop+64 (in /usr/lib64/libhdf5.so.103.1.0) ==6297== by 0x4A56465: H5P__do_prop_cb1.part.13+85 (in /usr/lib64/libhdf5.so.103.1.0) ==6297== by 0x4A55C01: H5P_create_id+385 (in /usr/lib64/libhdf5.so.103.1.0) ==6297== by 0x4A56155: H5P__init_package+373 (in /usr/lib64/libhdf5.so.103.1.0) ==6297== by 0x4A562C7: H5P_init+39 (in /usr/lib64/libhdf5.so.103.1.0) ==6297== by 0x48CA0ED: H5_init_library+285 (in /usr/lib64/libhdf5.so.103.1.0) ==6297== by 0x48CA90F: H5open+63 (in /usr/lib64/libhdf5.so.103.1.0) ==6297== by 0x1091C8: main+67 (h5simple.cpp:6) ----- I have no experience at all with objdump. I tried 'objdump -d ./h5s_8.3.0' (h5s_8.3.0 is my test-application compiled with g++ 8.3.0), I see some references to hdf5 calls (e.g. H5open, but no H5P_dup_prop), but i can't really interpret the output. I attached both the output of Valgrind and of objdump to this mail. Let me know how i can be of further help Regards Jody On Sun, Dec 29, 2019 at 10:34 AM Julian Seward <bugzilla_nore...@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=393351 > > --- Comment #14 from Julian Seward <jsew...@acm.org> --- > 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. > > -- > You are receiving this mail because: > You are on the CC list for the bug. -- You are receiving this mail because: You are watching all bug changes.
