I found a bug in pdfTeX that caused the inclusion of uninitialized memory when certain kinds of images were used.
PDFExcess.java is a program to scan PDFs for this bug and extract any uninitialized memory they contain.
The function write_png_rgb_alpha allocates twice as much memory as is
necessary for the smask buffer. The second half of the buffer is left
uninitialized and the whole buffer is copied to the output PDF file.
I think the bug is in texk/web2c/pdftexdir/writepng.c, where a "/ 2"
should be "/ 4"; i.e., 1 in 4 bytes is an alpha byte:
smask_size = (png_get_rowbytes(png_ptr(img), png_info(img)) / 2)
* png_get_image_height(png_ptr(img), png_info(img));
Interestingly, texk/web2c/luatexdir/image/writepng.w gets it right:
smask_size = (int) ((png_get_rowbytes(png_p, info_p) / 4) * png_get_image_height(png_p, info_p));
I attached files that demonstrate the error when run in Valgrind. The
first pair, test-rgb.tex and img-rgb.png, don't have the error because
the image doesn't have an alpha channel and goes through write_png_rgb
rather than write_png_rgb_alpha:
$ valgrind pdflatex test-rgb
The second pair, test-rgba.tex and img-rgba.png, show many errors. (The
stack trace says write_png_gray_alpha rather than write_png_rgb_alpha,
but I believe that is an optimization artifact.)
$ valgrind pdflatex test-rgba
...
<img-rgba.png, id=1, 100.375pt x 100.375pt> <use img-rgba.png> [1{/var/lib/texm
f/fonts/map/pdftex/updmap/pdftex.map} <./img-rgba.png==11091== Conditional jump or move depends on uninitialised value(s)
==11091== at 0x4C300D3: memcpy@GLIBC_2.2.5 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11091== by 0x506E425: ??? (in /lib/x86_64-linux-gnu/libz.so.1.2.8)
==11091== by 0x506EE67: ??? (in /lib/x86_64-linux-gnu/libz.so.1.2.8)
==11091== by 0x506FE53: deflate (in /lib/x86_64-linux-gnu/libz.so.1.2.8)
==11091== by 0x199F5A: writezip (writezip.c:71)
==11091== by 0x152179: pdfflush.part.39 (pdftex0.c:18948)
==11091== by 0x16B1E4: pdfflush (pdftex0.c:19087)
==11091== by 0x16B1E4: pdfendstream (pdftex0.c:19085)
==11091== by 0x18FA99: write_png_gray_alpha (writepng.c:288)
==11091== by 0x18FA99: write_png (writepng.c:652)
==11091== by 0x18A836: writeimage (writeimg.c:370)
==11091== by 0x16BB78: zpdfwriteimage (pdftex0.c:22285)
==11091== by 0x16D794: zpdfshipout (pdftex0.c:24722)
==11091== by 0x17F65C: maincontrol (pdftex0.c:38501)
In order to get line numbers in the stack trace, I had to install the
"texlive-binaries-dbgsym" Debian package.
https://wiki.debian.org/HowToGetABacktrace
Another way to verify is to set
\pdfcompresslevel=0
Then you can see that the pixel data of the 100×100 image has
/Length 30000
But the SMask data is twice as big as it should be:
/Length 20000
Here is my version information:
pdfTeX 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian)
kpathsea version 6.2.2
Copyright 2016 Han The Thanh (pdfTeX) et al.
There is NO warranty. Redistribution of this software is
covered by the terms of both the pdfTeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the pdfTeX source.
Primary author of pdfTeX: Han The Thanh (pdfTeX) et al.
Compiled with libpng 1.6.28; using libpng 1.6.28
Compiled with zlib 1.2.8; using zlib 1.2.8
Compiled with poppler version 0.48.0
Debian bug #796490 appears to be about this same issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796490
I discovered this problem while trying to make a reproducible PDF. I was
unable to get reproducibility of a particular document even after
following the suggestions of https://tex.stackexchange.com/a/313605:
\pdfinfoomitdate=1
\pdftrailerid{}
\pdfsuppressptexinfo=-1
The non-reproducibility was caused by uninitialized memory being copied
to the output file.