search

jaewonjoo / webp

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

scaled decodes seem to use uninitialized memory #254

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
In Skia (skia.org), we are using libwebp version 0.4.3.

We run tests that decode an image (at various scales) and then draw the result. 
Then we compare the results over time to see if we've made a change that 
generated a different result.

When we decode a webp image scaled, we see results that are different on almost 
every run. Most of the image looks the same, but there are some pixels along 
the right edge (that seem to be somewhat evenly spaced) that look slightly 
different.

We also run a valgrind bot which complains of using uninitialized memory, which 
I suspect is related. (An example is here: 
https://build.chromium.org/p/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2-x
86_64-Release-Valgrind/builds/295/steps/dm/logs/stdio.)

I have attached a sample image along with a couple of results (scaled to 0.625) 
and the difference between these two results.

Original issue reported on code.google.com by scro...@google.com on 13 Jul 2015 at 2:56

Attachments:

GoogleCodeExporter commented 8 years ago 
Thanks for the report. I imagine we'll be able to reproduce the report with 
cwebp. Just for definiteness can you give the dimensions you were scaling to 
rather than just the factor?

Original comment by jz...@google.com on 14 Jul 2015 at 4:15

GoogleCodeExporter commented 8 years ago 
This particular image was scaled to 200 x 147 in this instance, although we 
found similar behavior at several scales.

Original comment by scro...@google.com on 14 Jul 2015 at 4:43

GoogleCodeExporter commented 8 years ago 
I can reproduce this doing an upscale with 0.4.3 and the current tip of tree. A 
good way to achieve a difference is with different values of --malloc-fill:

$ valgrind \
  --track-origins=yes \
  --malloc-fill=0xcc \
  ./examples/dwebp \
  -ppm -scale 200 147 \
  5.sm.webp -o out.ppm

I'll have a closer look when I get a chance.

Original comment by jz...@google.com on 18 Jul 2015 at 2:54

GoogleCodeExporter commented 8 years ago 
there's apparently a buffer-read overflow happening at src/utils/rescaler.c:51, 
where 'x_in' can become equal to 'wrk->src_width' (shouldn't happen). 
Investigating and fixing...

Original comment by pascal.m...@gmail.com on 23 Jul 2015 at 5:01

GoogleCodeExporter commented 8 years ago 
Right one could clamp or perhaps bias 'accum' given the current precision. 
Increasing the precision would likely give a more accurate calculation of this 
coordinate.

Original comment by jz...@google.com on 23 Jul 2015 at 9:27