https://bugs.kde.org/show_bug.cgi?id=489088
Mark Wielaard <m...@klomp.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|REPORTED |CONFIRMED
--- Comment #6 from Mark Wielaard <m...@klomp.org> ---
(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?
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
(You can also get some of that with something like --trace-flags=10000000
--trace-notbelow=1000 but that is really verbose)
--
You are receiving this mail because:
You are watching all bug changes.
