https://bugs.kde.org/show_bug.cgi?id=489088
--- Comment #7 from Sam James <s...@gentoo.org> --- (In reply to Mark Wielaard from comment #6) > (In reply to Sam James from comment #5) > > (In reply to Mark Wielaard from comment #4) > > > See also https://bugs.kde.org/show_bug.cgi?id=391148 which comes with a > > > patch. > > > > Hi Mark, thanks for looking! > > > > That patch seems to work: > > > > ``` > > ==144687== Invalid read of size 8 > > ==144687== at 0x109F43: filter (test.c:59) > > ==144687== by 0x109F43: AnalyzeSamples (test.c:100) > > ==144687== by 0x109366: main (test.c:167) > > ==144687== Address 0x4637bfeabfe4bbd4 is not stack'd, malloc'd or > > (recently) free'd > > ==144687== > > ==144687== > > ==144687== Process terminating with default action of signal 11 (SIGSEGV): > > dumping core > > ==144687== General Protection Fault > > ==144687== at 0x109F43: filter (test.c:59) > > ==144687== by 0x109F43: AnalyzeSamples (test.c:100) > > ==144687== by 0x109366: main (test.c:167) > > ``` > > although the address looks a bit suspicious and I wasn't aware of out of > > bounds access in the testcase, so not sure if it really is decoding fully > > correctly? > > hmmm, yeah that is kind of odd. That address is so weird that it really must > be invalid. Does the original program also try to read from that address and > produce a SIGSEGV when not run under valgrind? Nope! > > Maybe as a quick hack check you could change that DIP("vmovq %s,%s\n", > nameXMMReg(rG), nameIReg64(rE)); in the patch to vex_printf(...) > > If it decodes correctly it should print vmovq %xmm12,%xmm0 > ==402260== vmovq %xmm12,%r8 vmovq %xmm14,%r10 ==402260== Invalid read of size 8 ==402260== at 0x109F46: filter (test.c:59) ==402260== by 0x109F46: AnalyzeSamples (test.c:100) ==402260== by 0x109366: main (test.c:167) ==402260== Address 0x4637bfeabfe4bbd4 is not stack'd, malloc'd or (recently) free'd -- You are receiving this mail because: You are watching all bug changes.
