search

kleopatra999 / webm

Automatically exported from code.google.com/p/webm
0 stars 0 forks source link

Dr. Memory reports uninitialized read at vp8/common/x86/subpixel_ssse3.asm:322 #844

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
http://build.webmproject.org/jenkins/job/libvpx__unit_tests-dr_memory/arch=x86-l
inux-gcc/lastBuild/HTML_Report/

All occur during TestVectorTest_MD5Match_Test

Yunqing: Assigning to you since you fixed the last batch of these. 
(sorry/thanks)

Original issue reported on code.google.com by tomfine...@google.com on 20 Aug 2014 at 6:51

GoogleCodeExporter commented 9 years ago 
I was testing an updated Dr. Memory (1.8.x) and I believe these were suppressed 
like valgrind. The runtime appeared to have increased, but we can upgrade if it 
quiets some of these harmless warnings.

Original comment by jz...@google.com on 10 Oct 2014 at 2:00

GoogleCodeExporter commented 9 years ago 
If I remember correctly, didn't we add some unnecessary instructions to quiet 
the errors from Dr. Memory?

Is Chrome on 1.8.x?
If the old code is faster and doesn't cause an issue with 1.8.x, should we put 
the old code back in?

Original comment by fgalli...@google.com on 10 Oct 2014 at 4:33

GoogleCodeExporter commented 9 years ago 
Jingning fixed an issue recently. Could you check if it fixes this issue too?

commit  5fcbcf1b22a92a2c13381b91c216200f073e0b74
Move the high freq coeff check outside store_coding_context
This fixes valgrind message issue 870.

Original comment by yunqingw...@google.com on 10 Oct 2014 at 4:45

GoogleCodeExporter commented 9 years ago 
The Dr. Memory test runs regularly:

http://build.webmproject.org/jenkins/view/libvpx-nightly-tests/job/libvpx__unit_
tests-dr_memory/arch=x86-linux-gcc/HTML_Report/

I don't think Jingning's change will make a difference these have been there a 
while.

Original comment by jz...@google.com on 10 Oct 2014 at 6:26

GoogleCodeExporter commented 9 years ago 
> If I remember correctly, didn't we add some unnecessary instructions to quiet 
the errors from Dr. Memory?

Yes I think so [1][2][3], there might be others.

> Is Chrome on 1.8.x?

Not sure.

> If the old code is faster and doesn't cause an issue with 1.8.x, should we 
put the old code back in?

sgtm.

[1] https://gerrit.chromium.org/gerrit/#/c/69313/
[2] https://gerrit.chromium.org/gerrit/#/c/69839/
[3] https://gerrit.chromium.org/gerrit/#/c/69546/

Original comment by jz...@google.com on 10 Oct 2014 at 6:28

GoogleCodeExporter commented 9 years ago 
Is this fixed?

Original comment by fgalli...@google.com on 17 Jan 2015 at 12:09

GoogleCodeExporter commented 9 years ago 
I thought this was fixed (please see my previous comment). I remembered I 
talked to Tom about it.

Tom, did you still see the issue in Dr memory test result?

Original comment by yunqingw...@google.com on 17 Jan 2015 at 12:40

GoogleCodeExporter commented 9 years ago 
latest completed run is here:

http://build.webmproject.org/jenkins/job/libvpx__unit_tests-dr_memory/215/arch=x
86-linux-gcc/HTML_Report/

I haven't upgraded jenkins to 1.8.x.

Original comment by jz...@google.com on 17 Jan 2015 at 12:43

GoogleCodeExporter commented 9 years ago 
These appear to be suppressed with (Linux) 1.8.0-8.

Original comment by jz...@google.com on 17 Jan 2015 at 4:22

GoogleCodeExporter commented 9 years ago

Original comment by jz...@google.com on 17 Jan 2015 at 4:24