Closed Bug 1511603 Opened Last year Closed 11 months ago
Assertion Crash [@ qcms
_transform _data _rgb _out _lut | mozilla::image::ns Web PDecoder::Apply Color Profile ]
1. https://www.warhistoryonline.com/guest-bloggers/3-myths-montana-class-battleships.html 2. Crash/Assert Nightly Windows/Linux but not Beta though Bughunter didn't see this particular crash which I reproduced locally with a Linux debug build. firefox: gfx/qcms/transform.c:1380: qcms_transform *qcms_transform_create(qcms_profile *, qcms_data_type, qcms_profile *, qcms_data_type, qcms_intent): Assertion `0 && "input type"' failed. Program firefox-debug/dist/bin/firefox (pid = 19287) received signal 6. Stack: #01: __restore_rt (sigaction.c:?) #02: __GI_raise (:?) #03: __GI_abort (:?) #04: _nl_load_domain.cold.0 (loadmsgcat.c:?) #05: .annobin_assert.c_end (assert.c:?) #06: qcms_transform_data_rgb_out_lut (gfx/qcms/transform.c:809) #07: mozilla::image::nsWebPDecoder::ApplyColorProfile(char const*, unsigned long) (image/decoders/nsWebPDecoder.cpp:315) #08: mozilla::image::nsWebPDecoder::ReadHeader(WebPDemuxer*, bool) (image/decoders/nsWebPDecoder.cpp:343) #09: mozilla::image::nsWebPDecoder::ReadData() (:?) #10: mozilla::image::nsWebPDecoder::UpdateBuffer(mozilla::image::SourceBufferIterator&, mozilla::image::SourceBufferIterator::State) (:?) #11: mozilla::image::nsWebPDecoder::DoDecode(mozilla::image::SourceBufferIterator&, mozilla::image::IResumable*) (firefox-debug/dist/include/mozilla/Variant.h:598) #12: mozilla::image::Decoder::Decode(mozilla::image::IResumable*) (image/Decoder.cpp:125) #13: mozilla::image::DecodedSurfaceProvider::Run() (image/DecodedSurfaceProvider.cpp:125) #14: mozilla::image::DecodePoolWorker::Run() (firefox-debug/dist/include/mozilla/RefPtr.h:61)
This comes from the initial landing of webp. <https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=fc68a2bccde267e01879e637f0ceec3168983039&tochange=f8fefc9626c12c7e3f48bdd82baab9fc4edec345>
reduced test case isn't even webp: <https://www.warhistoryonline.com/wp-content/uploads/2017/02/montana-line-drawing-640x137.jpg>
Looks like the problem is that we always pass RGBA for the input color type to qcms, but this image is grayscale, and it's embedded color profile is to be apply to grayscale. We fail safely, and the result is the image doesn't get color corrected.
(In reply to Bob Clary [:bc:] from comment #2) > reduced test case isn't even webp: > <https://www.warhistoryonline.com/wp-content/uploads/2017/02/montana-line- > drawing-640x137.jpg> The server seems to be sending me webp. This happens for some servers using older versions of plugins designed to automatically handle webp. A quick survey of the webp library seems to indicate there is no way to get a format out of it other than full color. (Whereas png and jpeg have grayscale modes.) So it looks like the webp was autoconverted from a grayscale jpeg and the colorprofile made the transition untouched, but as the webp is full color the color profile no longer applies.
Assignee: aosmond → tnikkel
Attachment #9032877 - Flags: review?(aosmond)
Comment on attachment 9032877 [details] [diff] [review] qcmsgraywebp Review of attachment 9032877 [details] [diff] [review]: ----------------------------------------------------------------- LGTM.
Attachment #9032877 - Flags: review?(aosmond) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/0112129c8f4d Ignore grayscale color profiles in webp images because webp images are never grayscale. r=aosmond
Please request Beta approval on this when you get a chance.
Comment on attachment 9032877 [details] [diff] [review] qcmsgraywebp [Beta/Release Uplift Approval Request] Feature/Bug causing the regression: Bug 1503653 User impact if declined: just debug build (fatal) asserts Is this code covered by automated tests?: No Has the fix been verified in Nightly?: No Needs manual test from QE?: No If yes, steps to reproduce: load image in comment 2 List of other uplifts needed: None Risk to taking this patch: Low Why is the change risky/not risky? (and alternatives if risky): not risky. same behaviour with/without patch, just we ignore the color profile before we hit the assert in debug builds String changes made/needed: none
Attachment #9032877 - Flags: approval-mozilla-beta?
Comment on attachment 9032877 [details] [diff] [review] qcmsgraywebp [Triage Comment] Fixes an assertion in the new WebP code. Approved for 65.0b8.
Attachment #9032877 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.