You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for all your work on LodePNG. It’s appreciated.
On macOS, compiled with Clang, pngdetail -r ‹PNG-file› always crashes when given a 256×256 or 512×512 RGBA-8 PNG file.
[It probably crashes on any power-of-two multiples of these sizes & many other sizes too. And any pixel format.]
I’ve tracked it down to the rescale function in pngdetail.cpp.
The function appears to always access 1 element beyond the end of the std::vector.
[You were often getting away with it but for these images the vector’s data size is an exact (large-ish) power-of-two probably resulting in a full virtual memory page being allocated, so the array[size+1] access causes a page fault/illegal address exception.]
int index0 = x * numchannels + y0 * w1 * numchannels;
to
for(int x0 = xa; x0 <= xb; x0++) {
int index0 = x0 * numchannels + y * w0 * numchannels;
if (size_t(index0) >= in.size()) continue;
...
for(inty0 = ya; y0 <= yb; y0++) {
int index0 = x * numchannels + y0 * w1 * numchannels;
if (size_t(index0) >= temp.size()) continue;
appears to fix the problem. [BTW index0 should probably have been declared size_t.]
Also the std::vectors passed to & returned by rescale appear to always contain RGBA-16 big-endian images. However, only the high bytes of the RGBA components are used/needed. So you could effectively double the performance by changing:
Hello,
Thanks for all your work on LodePNG. It’s appreciated.
On macOS, compiled with Clang,
pngdetail -r ‹PNG-file›
always crashes when given a 256×256 or 512×512 RGBA-8 PNG file.[It probably crashes on any power-of-two multiples of these sizes & many other sizes too. And any pixel format.]
I’ve tracked it down to the
rescale
function inpngdetail.cpp
.The function appears to always access 1 element beyond the end of the
std::vector
.[You were often getting away with it but for these images the vector’s data size is an exact (large-ish) power-of-two probably resulting in a full virtual memory page being allocated, so the array[size+1] access causes a page fault/illegal address exception.]
Changing:
lodepng/pngdetail.cpp
Lines 470 to 471 in 0b1d9cc
lodepng/pngdetail.cpp
Lines 491 to 492 in 0b1d9cc
to
appears to fix the problem. [BTW
index0
should probably have been declaredsize_t
.]Also the
std::vector
s passed to & returned byrescale
appear to always contain RGBA-16 big-endian images. However, only the high bytes of the RGBA components are used/needed. So you could effectively double the performance by changing:lodepng/pngdetail.cpp
Line 458 in 0b1d9cc
to
Also
lodepng/pngdetail.cpp
Line 747 in 0b1d9cc
should probably be:
And
lodepng/pngdetail.cpp
Line 1507 in 0b1d9cc
should probably be:
Finally adding
data.loadInspect();
as the first line in:lodepng/pngdetail.cpp
Line 1434 in 0b1d9cc
encourages
pngdetail -s ‹file›
&pngdetail -c ‹file›
to print some output.The text was updated successfully, but these errors were encountered: