etemesi254/zune-image

Panic when decoding images

sxyazi opened this issue ยท 7 comments

Hi, after upgrading to image v0.25.1 (image v0.25 switched to zune-jpeg), I occasionally encounter panic when decoding certain JPEGs.

I found the code location that causes it based on the stack trace:

// it may happen that some images don't have the whole buffer
// so we can't panic in case of that
// assert_eq!(pixels_written, pixels.len());

And it was fixed in 1f943d8, but the latest zune-jpeg 0.4.11 does not include this fix. Is it possible to release a new patch version for it?

working on it, sorry for the crash, it just happens that it was reported when i was overhauling the api and couldn't hot fix it

How about adding a regression test for this case? To ensure that this does not happen again in the future.

Thank you @uklotzde for the suggestion, I thought I had added a testcase but was for another problem.

Added in 2128376

Also fixed this in 0.5.0-rc0 which is now up in crates.io So closing this.

Thank you for reporting

Hi, is it possible to release a 0.4.12 version that removes this assert? I ran into it on this seemingly valid image

sadcomp

(I promise I didn't mess with this image on purpose to trigger this. I've had it floating around since 2020 ๐Ÿ˜…)

Hi, is it possible to release a 0.4.12 version that removes this assert? I ran into it on this seemingly valid image

This would be a low effort quick fix to resolve the issue temporarily. Clients will handle the subsequent decoding error gracefully.

Many downstream dependencies that have upgraded to image v0.25.x are affected. Crashing applications for no valid reason is very inconvenient.

...especially now since image v0.25 is actively promoted: https://www.reddit.com/r/rust/comments/1cj94va/image_v025_performance_improvements/

Bump on releasing a 0.4.12 update to resolve this! Happy to help here and update the image crate as needed.