Closed Bug 1511603 Opened Last year Closed 11 months ago

Assertion Crash [@ qcms_transform_data_rgb_out_lut | mozilla::image::nsWebPDecoder::ApplyColorProfile ]


(Core :: ImageLib, defect)

Not set



Tracking Status
firefox-esr60 --- unaffected
firefox63 --- unaffected
firefox64 --- unaffected
firefox65 --- verified
firefox66 --- verified


(Reporter: bc, Assigned: tnikkel)


(Blocks 1 open bug, )


(Keywords: assertion, regression)


(1 file)


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.

#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)
Assignee: nobody → aosmond
Flags: needinfo?(aosmond)
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:
> <
> 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.
Duplicate of this bug: 1515825
Attached patch qcmsgraywebpSplinter Review
Assignee: aosmond → tnikkel
Attachment #9032877 - Flags: review?(aosmond)
Comment on attachment 9032877 [details] [diff] [review]

Review of attachment 9032877 [details] [diff] [review]:

Attachment #9032877 - Flags: review?(aosmond) → review+
Flags: needinfo?(aosmond)
Pushed by
Ignore grayscale color profiles in webp images because webp images are never grayscale. r=aosmond
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Please request Beta approval on this when you get a chance.
Flags: needinfo?(tnikkel)
Comment on attachment 9032877 [details] [diff] [review]

[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
Flags: needinfo?(tnikkel)
Attachment #9032877 - Flags: approval-mozilla-beta?
Comment on attachment 9032877 [details] [diff] [review]

[Triage Comment]
Fixes an assertion in the new WebP code. Approved for 65.0b8.
Attachment #9032877 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Considering this bug actually needs verification, where do I get e debug build from? I can't reproduce this issue on an asan reporter build and I'm not sure where I get an affected build from. Bob, can you help me?

Flags: needinfo?(bob)
Flags: needinfo?(bob)

I have tried a bunch of debug builds from the period when the bug was logged and neither of them reproduced the issue (the builds on Windows 10 x64 crashed at launch, the ones on Ubuntu 16 x63 did not crash).

Can you reproduce it on a newly created profile (on an affected build, of course)? If yes, can you give me some information about the systems it reproduced on?

I can't validate the fix if I can't reproduce it. In the last case scenario, you could verify the fix on the system it reproduced on, for both the latest Beta and the latest Nightly.

Thank you!

Flags: needinfo?(bob)

on fedora 29 x86_64
opt - no crash
debug - crash

with mozilla-central builds from yesterday
opt - no crash
debug - crash

Flags: needinfo?(bob)
You need to log in before you can comment on or make changes to this bug.