Check a possibly better solution for Huffman decoder issue from Bug 1050342
Categories
(Core :: Graphics: ImageLib, task, P3)
Tracking
()
People
(Reporter: Nomis101, Unassigned)
References
Details
Attachments
(1 obsolete file)
In Bug 1050342 a case was fixed where the fast huffman decoder in libjpeg-turbo can produce different results depending on how data is fed to it. This change was not accepted upstream into libjpeg-turbo. There is now a fix for this issue in libjpeg-turbo, which would make the hack from Bug 1050342 unnecessary.
See https://github.com/libjpeg-turbo/libjpeg-turbo/commit/8fa70367ed5bbdc0685494e8212d975b5c89a77d
and
https://github.com/libjpeg-turbo/libjpeg-turbo/issues/420
NOTE: ASan complained about removing the "& 0xFF" with certain test cases, so it has been reinstated:
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/4de8f6922a9be7d0a51a429e367283fd40031b26
I'll let you know if any other relevant bugs are discovered prior to the 2.1 release.
Updated•3 years ago
|
Comment 2•3 years ago
|
||
I don't really remember this code, and I wasn't ever an expert in it. If dcommander thinks it's a proper fix, and it fixes the original issue so that uninitialized memory is not reported by valgrind or any other tool then I'm happy with it.
I simply performed the same tests performed in https://bugzilla.mozilla.org/show_bug.cgi?id=1050342. Those tests reproduced the issue without the patch and no longer reproduced the issue with the patch. I'd feel better if Noel could sign off on it, since he developed those tests.
Comment hidden (spam) |
Updated•2 months ago
|
Description
•