Closed Bug 1395394 Opened 3 years ago Closed 3 years ago

Crash in mozilla::gfx::gfxGradientCache::GetGradientStops

Categories

(Core :: Web Painting, defect)

Unspecified
Windows 10
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla58
Tracking Status
firefox-esr52 --- unaffected
firefox56 --- unaffected
firefox57 --- unaffected
firefox58 --- fixed

People

(Reporter: marcia, Assigned: bas.schouten)

References

Details

(Keywords: crash, regression, topcrash)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-34118bd6-00a1-4176-b2b5-130130170825.
=============================================================

Seen while looking at crash stats: http://bit.ly/2gqcF1e. Looks as if first crash occurred in 20170817100132 build. So far 12 crashes/9 installs

Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6ebc251bd288c268b020815025b05854ccde5c08&tochange=932388b8c22c9775264e543697ce918415db9e23
It is my report.
Though I need to make sure, my prediction is that probably omtp is related to the crash...
(In a time frame I reported crashes(1/3 of all recent reports!), omtp is enabled)
OK, I tested without omtp for a while, and I can't reproduce this crash at all.
So, apparently, this crash is triggered by omtp.
Is omtp shipping in 57?
Flags: needinfo?(yamadat501)
No, I enabled it through about:config.
Flags: needinfo?(yamadat501)
According to Bas/milan on #gfx, omtp won't ship in 57. Updating.
Now that OMTP is enabled by default on Windows (https://hg.mozilla.org/mozilla-central/rev/843b90c48664). I think you might want to fix this crash. It crashes frequently (not always tho) here, for example on this site https://naekranie.pl/.
There are 241 crashes in nightly 58 starting with buildid 20170929220356. Before this build, this crash was quite rare.
The signature is now ranked #8 for nightly top-crashers for content process.
:bas, could you investigate please ?
Flags: needinfo?(bas)
Keywords: topcrash
Bas, two thoughts: First, we skip this code when recording. It looks like it should be supported by capturing though. Second, GradientStops is not threadsafe-refcounted, so maybe there is a race between the cache and paint thread.

[1] http://searchfox.org/mozilla-central/rev/c296ed9811319cdd61ac35e9e648f95639cda726/gfx/thebes/gfxGradientCache.cpp#205
[2] http://searchfox.org/mozilla-central/rev/c296ed9811319cdd61ac35e9e648f95639cda726/gfx/2d/2D.h#213
Flags: needinfo?(bas)
Comment on attachment 8914128 [details]
Bug 1395394: Make refcounting of GradientStops threadsafe for the sake of OMTP.

https://reviewboard.mozilla.org/r/185452/#review190342
Attachment #8914128 - Flags: review?(matt.woodrow) → review+
This is the #2 Windows topcrash in Nightly 20170929220356.
Pushed by bschouten@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7667e2b40236
Make refcounting of GradientStops threadsafe for the sake of OMTP. r=mattwoodrow
Assignee: nobody → bas
https://hg.mozilla.org/mozilla-central/rev/7667e2b40236
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Duplicate of this bug: 1404655
You need to log in before you can comment on or make changes to this bug.