Closed Bug 1757881 Opened 2 years ago Closed 2 years ago

Firefox never closes file handles to all font files on the system

Categories

(Core :: Layout: Text and Fonts, defect)

defect

Tracking

()

RESOLVED DUPLICATE of bug 701661

People

(Reporter: whimboo, Unassigned)

References

Details

Attachments

(1 file)

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:100.0) Gecko/20100101 Firefox/100.0 ID:20220302065857

There are hundreds of open file handles to font files which seem to never be closed by Firefox. By a quick inspection it looks like that this might actually apply to all available fonts on my system + variants (bold, italic, etc) and they are all tight to the Firefox main process.

When comparing to Chrome with a new profile there is just two font files open.

Steps to reproduce:

  1. Start Firefox with a fresh profile
  2. Open the Activity Monitor on MacOS
  3. Find the main process and open the Inspect Process panel
  4. Select Open Files and Ports and copy the data from the textarea

Now you can observe that this list of files contains a huge amount of open file handles to all font variants. On my system it counts 336 open files. See the list of files in the attached file.

It also doesn't matter how long I wait, all these open files are never closed, even not after hours of work or if Firefox is idle in the background.

I'm not sure offhand whether we keep these open intentionally or not, but I did observe that this behavior has been around for quite a while -- I tested this on Mac, and I'm seeing 183 ttf fonts opened in current Nightly as well as Nightlies from years ago. (I'm meausring number-of-ttf-fonts-opened measured by doing lsof | grep firefox | grep ttf | wc -l, after letting Firefox-with-a-fresh-profile sit on its start page for 10-15 seconds).

I did see that it was lower before early 2014, though -- in Nightly 2014-01-29 and earlier, I get 60 ttf fonts open, instead of 183 (as measured by the above command). Whereas Nightly 2014-01-30 up through present-day all give me 183 ttf font files open.

The pushlog for this behavior change is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7e79536aca0a&tochange=73eefb421e2a
and I assume that "Bug 962440 async font info loader infrastructure with OSX implementation. r=bas" would be the relevant change there.

Anyway: jfkthame, do you know if this is expected behavior, i.e. do you know why we show all these fonts as being open whereas Chrome only shows a few? (And should we be concerned?)

Flags: needinfo?(jfkthame)

Looks like there's some related discussion on bug 491283, FWIW -- adding that to see-also. (though most of that predates bug 962440, and bug 491283 comment 38 suggests that the off-main-thread font loading [bug 962440] may have addressed the issues discussed in that bug.)

See Also: → 491283

Tentatively triaging as S3, but I'll defer to jfkthame if this is more or less severe (or even expected-behavior).

Severity: -- → S3

I think this is basically internal Core Text behavior; my recollection is that it appears to keep a file handle open to every font that gets touched, even though we release the references we're holding.

See bug 701661 for past discussion of the issue.

Is there any evidence that this causes actual problems for users?

Flags: needinfo?(jfkthame)

(In reply to Jonathan Kew (:jfkthame) from comment #4)

See bug 701661 for past discussion of the issue.

Thanks! Let's dupe this to that bug.

Is there any evidence that this causes actual problems for users?

(hskupin, you filed the bug - do you know of any issues caused by this, or did you just file because it seemed suspicious?)

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(hskupin)
Resolution: --- → DUPLICATE

(In reply to Daniel Holbert [:dholbert] from comment #5)

Is there any evidence that this causes actual problems for users?

(hskupin, you filed the bug - do you know of any issues caused by this, or did you just file because it seemed suspicious?)

After running Firefox for a couple of days and using hibernation a couple of times during the day and night the main process is is reaching a very high number (~148k) of open ports (see bug 1755701) causing problems for other applications in not being able to open a file. As such I'm trying to find out how to improve things and this was an obvious difference to other browsers.

Flags: needinfo?(hskupin)
No longer blocks: 1755701
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: