Intermittent TEST-UNEXPECTED-FAIL | leakcheck | tab process: 6008 bytes leaked (AsyncFontInfoLoader, FontInfoData, FontInfoLoadCompleteEvent, nsNameThreadRunnable, nsRunnable, ...)

RESOLVED WORKSFORME

Status

()

Core
Graphics: Text
P3
normal
RESOLVED WORKSFORME
2 years ago
2 months ago

People

(Reporter: philor, Assigned: jtd)

Tracking

({intermittent-failure, mlk})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
https://treeherder.mozilla.org/logviewer.html#?job_id=18194302&repo=mozilla-inbound
(Assignee)

Comment 1

2 years ago
Created attachment 8695601 [details] [diff] [review]
patch, cancel loader on teardown

This should happen via the shutdown observer but maybe there's some way for the platform fontlist to be torn down without that observer firing? Can't reproduce this leak at this point so this is speculative.
Attachment #8695601 - Flags: review?(jfkthame)
(Assignee)

Updated

2 years ago
Assignee: nobody → jdaggett
(Assignee)

Updated

2 years ago
Component: General → Graphics: Text
Comment on attachment 8695601 [details] [diff] [review]
patch, cancel loader on teardown

Review of attachment 8695601 [details] [diff] [review]:
-----------------------------------------------------------------

This would be called when the platformFontList is being destroyed, which happens during gfxPlatform::Shutdown(), right? I don't know quite where that fits into the overall shutdown process, but I'm wondering whether it's wise to be firing off a new Runnable at this point, which is what CancelLoader() will do if there's currently a live mFontLoaderThread. Is the main thread still in a position to handle this, or are we too far into shutdown by this time?
Happened once, in December 2015.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 4

2 years ago
Twice.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Updated

2 years ago
Attachment #8695601 - Flags: review?(jfkthame)
(Assignee)

Comment 5

2 years ago
This has been resolved by the fix on bug 1241931.
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 6

2 years ago
Nope.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 7

2 years ago
5 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-inbound: 4
* try: 1

Platform breakdown:
* osx-10-10: 2
* linux64: 2
* osx-10-6: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1230043&startday=2016-04-18&endday=2016-04-24&tree=all

Comment 8

a year ago
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.