[Bug 1870827] Re: Firefox hangs after simultaneously opening Chrome/Electron-based applications

Bug Watch Updater 1870827 at bugs.launchpad.net
Thu Apr 23 14:13:18 UTC 2020


Launchpad has imported 53 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=1495900.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2018-10-02T21:53:50+00:00 L. David Baron wrote:

Sometime in the past few weeks I've noticed a regression:  when I start
Chromium (Ubuntu's packaged version of it) to test something, all of my
Firefox content processes hang for about 2 minutes.  This is pretty bad!

Today I decided to profile, and the profile at https://perfht.ml/2y8pYIS
showed what I expected to be the problem:  FontConfig.  In particular,
we spend basically all of the time inside FcInitReinitialize.

I'm not sure if the thing that caused the regression is something in
Chromium (e.g., a change in version 69, which I got the upgrade to on
2018-09-12, which seems plausible for when this started happening), or
whether the regression is on the Firefox side.

[Tracking Requested - why for this release]:
Either way, spending this much time rescanning font directories just because I started Chromium doesn't seem acceptable, and seems likely to be problematic for any Web developers running Linux.

On the flip side, it's possible my times are particularly long because I
have a lot of fonts installed.  (I don't have a particularly large
number of active tabs -- probably about 20-30, though I have a very
large number of dormant tabs that haven't been loaded but are part of my
session.  If we do something once per tab, that could certainly be a
problem...)

The bulk of the time (again, see the profile at https://perf-
html.io/public/e0db389afe6c3fdcafc8df3db7f0ec0447a1f432 ) is spent in
stacks like this:

TT_New_Context
FT_Load_Glyph
FcPatternFormat
FcPatternFormat
FcFreeTypeQueryFace
FcFileIsDir
FcFileIsDir
FcDirScan
FcConfigAppFontClear
FcConfigBuildFonts
FcInitLoadConfig
FcInitReinitialize
gtk_settings_get_type
g_closure_invoke
g_signal_handler_disconnect
g_signal_emit_valist
g_signal_emit
g_cclosure_marshal_BOOLEAN__BOXED_BOXEDv
g_object_notify_by_pspec
gtk_main_do_event
gdk_event_free
gdk_x11_drag_context_get_type
g_main_context_dispatch
g_main_context_dispatch
g_main_context_iteration
nsAppShell::ProcessNextNativeEvent(bool)
nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool)
non-virtual thunk to nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool)
nsThread::ProcessNextEvent(bool, bool*)
NS_ProcessNextEvent(nsIThread*, bool)
mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*)
MessageLoop::Run()
nsBaseAppShell::Run()
XRE_RunAppShell()
MessageLoop::Run()
XRE_InitChildProcess(int, char**, XREChildData const*)
XRE_InitChildProcess

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/0

------------------------------------------------------------------------
On 2018-10-03T08:09:43+00:00 Jfkthame wrote:

Looks like this is not only within fontconfig, it's within fontconfig
called from GTK code. That seems like it may not really be under our
control. I guess what's happening is that when chromium is started, it's
changing the (global) fontconfig configuration in such a way that
fontconfig (in any process that uses it) decides it needs to
reinitialize everything.

What version of fontconfig is installed? This might be a fontconfig
issue that is fixed in newer versions; see also bug 1411338 comment 11.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/1

------------------------------------------------------------------------
On 2018-10-04T00:46:50+00:00 L. David Baron wrote:

$ dpkg -l 'fontconfig*' | grep "^ii"
ii  fontconfig        2.12.6-0ubuntu2 amd64        generic font configuration library - support binaries
ii  fontconfig-config 2.12.6-0ubuntu2 all          generic font configuration library - configuration

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/2

------------------------------------------------------------------------
On 2018-10-04T01:05:59+00:00 L. David Baron wrote:

Created attachment 9014241
more accurate callstack

Here's a more accurate callstack from gdb.

There seems to be a single call per child process, and that single call
really does take a few minutes.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/3

------------------------------------------------------------------------
On 2018-10-04T01:07:24+00:00 L. David Baron wrote:

Oh, and the version you really wanted is:
ii  libfontconfig1:amd64        2.12.6-0ubuntu2 amd64        generic font configuration library - runtime
ii  libfontconfig1:i386         2.12.6-0ubuntu2 i386         generic font configuration library - runtime
but it's the same.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/4

------------------------------------------------------------------------
On 2018-10-04T11:45:49+00:00 Jfkthame wrote:

Judging by the discussion in bug 1411338, I suspect this is a fontconfig
2.12.x issue and the fix is to update to fontconfig-2.13 or later. Could
you try that and confirm whether it resolves the problem?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/5

------------------------------------------------------------------------
On 2018-10-04T22:07:16+00:00 L. David Baron wrote:

(In reply to Jonathan Kew (:jfkthame) from comment #5)
> Judging by the discussion in bug 1411338, I suspect this is a fontconfig
> 2.12.x issue and the fix is to update to fontconfig-2.13 or later. Could you
> try that and confirm whether it resolves the problem?

That reduces the pause from 2-3 minutes to about 4-5 seconds, though
there's still a pause.

(I updated to the fontconfig packages from cosmic (i.e., Ubuntu 18.10),
which are version 2.13.0-5ubuntu3.)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/6

------------------------------------------------------------------------
On 2018-10-16T22:02:05+00:00 Jfkthame wrote:

*** Bug 1492360 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/7

------------------------------------------------------------------------
On 2018-10-19T09:26:50+00:00 Julien Cristau wrote:

Is there anything we can do here to avoid/reduce the pause or is this a
wontfix?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/8

------------------------------------------------------------------------
On 2018-10-19T10:34:02+00:00 Jfkthame wrote:

I'm not sure. I don't see an obvious way forward, but the behavior is
pretty bad. :(

Are any other (gtk-using) applications similarly affected? Given that
the pause occurs because a fontconfig re-scan appears to be triggered
from inside gtk event-handling code, it seems like other processes might
be suffering the same issue.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/9

------------------------------------------------------------------------
On 2018-10-24T16:45:18+00:00 Jfkthame wrote:

*** Bug 1499824 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/10

------------------------------------------------------------------------
On 2018-10-25T20:17:29+00:00 Simon wrote:

Just wanted to pipe up and confirm that installing the latest fontconfig
packages from cosmic significantly reduced the wait time for me, which
makes running my tests a whole lot more manageable :)

For the record I just installed these debs:

http://mirrors.kernel.org/ubuntu/pool/main/f/fontconfig/fontconfig-config_2.13.0-5ubuntu3_all.deb
http://mirrors.kernel.org/ubuntu/pool/main/f/fontconfig/libfontconfig1_2.13.0-5ubuntu3_amd64.deb

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/11

------------------------------------------------------------------------
On 2018-11-01T03:33:23+00:00 Ryanvm wrote:

Is there anything more we can do here? Not sure what to do with the Fx64
tracking request since this sounds like an issue that's out of our
control.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/12

------------------------------------------------------------------------
On 2018-11-01T10:19:16+00:00 Jfkthame wrote:

I don't know of any way forward here, unfortunately.

The one thing I'd be curious to know is whether other Gtk-based
applications are similarly affected; it seems like they should be, given
that the issue seems to be happening where fontconfig is used from
within Gtk code rather than directly from Gecko. (It may be much less
noticeable, though, if the app isn't visibly busy during the Chrome
launch.)

David, can you try to see whether other apps are affected on your
system, especially when using the older fontconfig? If this actually is
unique to Firefox, that would suggest there might be something about how
we use Gtk that's provoking it.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/13

------------------------------------------------------------------------
On 2018-11-03T23:28:56+00:00 Byte Commander wrote:

*** Bug 1504461 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/14

------------------------------------------------------------------------
On 2018-11-06T13:50:24+00:00 Julien Cristau wrote:

FWIW I asked a contact on the ubuntu desktop team a couple of weeks ago,
it sounds like they hadn't seen this reported on their side, either for
firefox or other applications.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/15

------------------------------------------------------------------------
On 2018-11-13T19:55:42+00:00 L. David Baron wrote:

I'm reasonably confident that gnome-terminal wasn't affected, although I
didn't retest (by downgrading) just now.  Are there other apps that are
more Firefox-like that you'd want me to check?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/16

------------------------------------------------------------------------
On 2018-11-13T20:08:54+00:00 L. David Baron wrote:

I tried setting a breakpoint on settings_update_fontconfig in some other
GTK apps (gnome-system-monitor, gnome-terminal-server), and I didn't
even hit it when starting Chromium, whereas I do hit it in Firefox.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/17

------------------------------------------------------------------------
On 2018-11-13T20:45:17+00:00 Jfkthame wrote:

I wonder if apps like gnome-system-monitor or terminal don't do as much
with font configuration? How about something like Gedit or  LibreOffice
-- do they hit settings_update_fontconfig at all?

Speculation: maybe it's related to the fact that we register a callback
to be notified when there's a change in Gtk default settings (see
<https://searchfox.org/mozilla-
central/rev/007b66c1f5f7a1b9a900a2038652a16a020f010c/widget/gtk/nsWindow.cpp#4073-4081>).
If you comment out that block of code, does it make any difference?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/18

------------------------------------------------------------------------
On 2018-11-13T20:48:31+00:00 L. David Baron wrote:

So one difference I found between Firefox and gnome-system-monitor is
that in Firefox, we execute this check_manager_window function that sets
up the gdk_xsettings_manager_window_filter event filter that leads to an
XEvent (property change) being turned into the fontconfig notification.
However, in gnome-system-monitor there's a call to gtk_init but it
doesn't reach check_manager_window.

Here's the Firefox callstack:
#0  0x00007f071684ebf0 in check_manager_window (x11_screen=0x5612c32c4020 [GdkX11Screen], notify_changes=notify_changes at entry=0) at ../../../../../gdk/x11/xsettings-client.c:527
#1  0x00007f071684edc6 in _gdk_x11_xsettings_init (x11_screen=<optimized out>)
    at ../../../../../gdk/x11/xsettings-client.c:618
#2  0x00007f0716830e3c in _gdk_x11_display_open (display_name=<optimized out>)
    at ../../../../../gdk/x11/gdkdisplay-x11.c:1608
#3  0x00007f0716805d5d in gdk_display_manager_open_display (manager=<optimized out>, name=0x5612c32a1480 ":0") at ../../../../gdk/gdkdisplaymanager.c:472
#4  0x00007f0716cf4ffa in gtk_init_check (argc=<optimized out>, argv=<optimized out>)
    at ../../../../gtk/gtkmain.c:1104
#5  0x00007f0716cf5029 in gtk_init (argc=<optimized out>, argv=<optimized out>)
    at ../../../../gtk/gtkmain.c:1161
#6  0x00007f070b12d90c in mozilla::dom::ContentChild::Init(MessageLoop*, int, char const*, IPC::Channel*, unsigned long, bool) (this=0x5612c329d060, aIOLoop=
    0x7f0703d66cc8, aParentPid=10218, aParentBuildID=0x7ffd28fa8a3a "20180917145248", aChannel=0x7f06fc002560, aChildID=1, aIsForBrowser=<optimized out>)
    at /home/dbaron/builds/mozilla-central/mozilla/dom/ipc/ContentChild.cpp:656

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/19

------------------------------------------------------------------------
On 2018-11-13T20:50:04+00:00 L. David Baron wrote:

gedit, like gnome-system-manager, does not hit
settings_update_fontconfig, and also does not call check_manager_window
within gtk_init.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/20

------------------------------------------------------------------------
On 2018-11-13T20:53:24+00:00 L. David Baron wrote:

And the difference is because in gedit, gdk_display_manager_open_display
tries _gdk_wayland_display_open first, and it succeeds, so there's no
x11 display at all.  So, basically, I think it doesn't happen in gedit
because the notification code for fontconfig changes was never hooked up
for wayland.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/21

------------------------------------------------------------------------
On 2018-11-13T21:00:18+00:00 L. David Baron wrote:

Not sure if the above leads to anything useful...

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/22

------------------------------------------------------------------------
On 2018-11-23T16:12:10+00:00 Mike Conley wrote:

*** Bug 1499385 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/23

------------------------------------------------------------------------
On 2018-12-03T15:47:32+00:00 Julien Cristau wrote:

This is likely wontfix for 64 at this point, though it'd be good to
figure out a way to avoid this.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/24

------------------------------------------------------------------------
On 2019-05-30T04:14:25+00:00 Mike Conley wrote:

*** Bug 1554588 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/25

------------------------------------------------------------------------
On 2019-06-03T02:15:37+00:00 Hikezoe-birchill wrote:

FWIW, this issue probably also happens with Android Emulator as well.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/26

------------------------------------------------------------------------
On 2019-06-03T02:38:26+00:00 Lsalzman wrote:

(In reply to Hiroyuki Ikezoe (:hiro) from comment #26)
> FWIW, this issue probably also happens with Android Emulator as well.

Android does not use FontConfig, so is not affected by this.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/27

------------------------------------------------------------------------
On 2019-06-03T02:51:20+00:00 Hikezoe-birchill wrote:

(In reply to Lee Salzman [:lsalzman] from comment #27)
> (In reply to Hiroyuki Ikezoe (:hiro) from comment #26)
> > FWIW, this issue probably also happens with Android Emulator as well.
> 
> Android does not use FontConfig, so is not affected by this.

Oh, you mean qemu or something like that doesn't use it at all on Linux?
I've been seeing quite often similar issue when I run the emulator.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/28

------------------------------------------------------------------------
On 2019-06-03T02:59:12+00:00 Hikezoe-birchill wrote:

Hmm actually qemu-system-x86_64 doesn't linked to libfontconfig.so (I am
not sure it's dynamically loaded or not), so probably some other
processes might affect Firefox.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/29

------------------------------------------------------------------------
On 2019-07-18T04:31:18+00:00 0vximcmlxxv wrote:

(In reply to svansintjan from comment #11)
> Just wanted to pipe up and confirm that installing the latest fontconfig
> packages from cosmic significantly reduced the wait time for me, which makes
> running my tests a whole lot more manageable :)
> 
> For the record I just installed these debs:
> 
> http://mirrors.kernel.org/ubuntu/pool/main/f/fontconfig/fontconfig-config_2.
> 13.0-5ubuntu3_all.deb
> http://mirrors.kernel.org/ubuntu/pool/main/f/fontconfig/libfontconfig1_2.13.
> 0-5ubuntu3_amd64.deb

Looks like the files specified in these links have a problem. Firefox is
complaining that the files have 'Virus or Malware' when trying to
download them. I downloaded the same package from 'Launchpad.net', it
did not complain -
https://launchpad.net/ubuntu/disco/amd64/fontconfig/2.13.1-2ubuntu2

Probably the links need to be removed and people should download the
packages from Launchpad.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/30

------------------------------------------------------------------------
On 2019-11-15T14:01:33+00:00 Mike Conley wrote:

*** Bug 1562544 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/31

------------------------------------------------------------------------
On 2019-11-23T15:05:27+00:00 Jfkthame wrote:

*** Bug 1580016 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/32

------------------------------------------------------------------------
On 2019-12-05T22:37:48+00:00 7-contacto-1 wrote:

I am using Ubuntu 18.04, is it possible to fix this? I cant seem to
install the deb files provided.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/33

------------------------------------------------------------------------
On 2019-12-18T09:46:44+00:00 Norsemanna wrote:

Hi folks,

> David, can you try to see whether other apps are affected on your
system

actually, when in my spare time, there are only three desktop apps that i use on my system: 
Firefox, Chromium, and skype. There is actually no difference in handling w.r.t this problem.
So starting skype oftentimes freezes chromium and  firefox, as well as starting chromium might freeze the others.

>This is likely wontfix for 64 at this point, though it'd be good to
figure out a way to avoid this.

Well, we are at 71 now (in my distribution), and the problem is still
there.

>That reduces the pause from 2-3 minutes to about 4-5 seconds, though
there's still a pause.

Well, even 4-5 seconds are too much, when there is a video or  a real time financial trader running in the browser,
or a chat with a friend just having asked you the "ultimate question" and you cannot answer for several minutes ....

---

As user "contacto" above, I cannot install 2.13 on my system due to
missing dependencies, and the next stable long time version will not
come so soon.

Can you please let us know, why firefox has to do this job
synchroneously and wait for fontconfig to finish? Can't that be done in
an async way?

Why does firefox have to update the fonts anyway? If the user installs
new fonts, why just don't wait until the user restarts firefox to see
the new fonts in the app? How about a user-option to opt-out of this
behaviour?

Finally: What can we do now to fix this problem?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/34

------------------------------------------------------------------------
On 2020-01-13T15:09:14+00:00 Morgan Wahl wrote:

I seem to have run into this when starting [Atom](https://atom.io/),
which uses [Electron](https://electronjs.org/) (which is itself based on
Chromium).

Every firefox process is at max CPU. Looking at strace it seems to
mainly hang out after opening a NotoSansCJK or NotoSerifCJK font. These
fonts have 2^16 - 1 glyphs, the maximum for a truetype font. It's
possible the delay wouldn't be perceivable without such large fonts
installed.

Firefox 72.0.1+build1-0ubuntu0.18.04.1
libfontconfig1 2.12.6-0ubuntu2
Ubuntu 18.04.3 LTS
x86-64

I believe I'm using X, not Wayland.

Can't seem to trigger it with other GTK apps. Tried epiphany, gedit,
evince, Gimp, Inkscape, QuodLibet, and LibreOffice Writer (not sure if
that's GTK), and Thunderbird (although I don't have an account
configured in Thunderbird).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/35

------------------------------------------------------------------------
On 2020-01-14T09:00:24+00:00 Norsemanna wrote:

Morgan,

yes, I have that fonts, too. But even when deactivating Noto*CJK*, the
load of the firefox (sub)processes/threads goes up to 95% (while with
the Noto*CJK fonts all of them went up to 100+%).

 Still waiting here for an answer that I can use as a workaround, since
I cannot install the 2.13 lib version.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/36

------------------------------------------------------------------------
On 2020-01-15T01:00:14+00:00 7-contacto-1 wrote:

Waiting for a workaround too :(

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/37

------------------------------------------------------------------------
On 2020-02-05T20:11:31+00:00 Corey-r wrote:

This is a very frustrating bug, hoping for a fix soon as possible.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/38

------------------------------------------------------------------------
On 2020-02-06T02:54:28+00:00 B-emilio wrote:

Out of curiosity, does this repro with `MOZ_DISABLE_CONTENT_SANDBOX=1`?
I expect it'd be at least much faster with that...

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/39

------------------------------------------------------------------------
On 2020-02-06T03:23:26+00:00 Hikezoe-birchill wrote:

No.  As far as I can tell it eliminates the hang completely.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/40

------------------------------------------------------------------------
On 2020-02-06T03:42:28+00:00 B-emilio wrote:

So this may be because we route all the system calls through the parent
process, which means that file reads from content have a _lot_ of
overhead... Next thing to figure out would be whether the FcReinitialize
stuff still happens consistently with the sandbox disabled...

Jed, do you know if the broker thread is registered with the profiler?
It'd be kinda cool to see where time is spent there if the sandboxing is
indeed the culprit.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/41

------------------------------------------------------------------------
On 2020-02-07T00:57:08+00:00 Jed Davis wrote:

I don't think they are, but that could be changed; [this is the top of
the broker threads' main function][main-start].

But something else to consider: is fontconfig trying to shell out to
`fc-cache` from the content processes?  That will fail under sandboxing,
and that might explain some of the difference between sandboxed and
unsandboxed.  One experiment to try there is to set
`security.sandbox.content.level` to 1, which should block `fork` but
allow direct (unbrokered) filesystem access.

[main-start]: https://searchfox.org/mozilla-
central/rev/3811b11b5773c1dccfe8228bfc7143b10a9a2a99/security/sandbox/linux/broker/SandboxBroker.cpp#623-630

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/42

------------------------------------------------------------------------
On 2020-02-14T01:11:00+00:00 Jed Davis wrote:

(In reply to David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-8 from comment #0)
> Today I decided to profile, and the profile at https://perfht.ml/2y8pYIS
> showed what I expected to be the problem:  FontConfig.  In particular, we
> spend basically all of the time inside FcInitReinitialize.

In particular, this appears to be spending almost all of the time doing
computations in fontconfig itself, not blocked on opening files (seen as
`recvmsg` with inverted call stacks), which — assuming the nature of the
problem hasn't changed since then — supports the idea that the cause of
the bad performance isn't the file brokering, but it might be fontconfig
falling back to ignoring a cache after failing to run an external
command to rebuild it.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/43

------------------------------------------------------------------------
On 2020-04-08T07:47:14+00:00 Alexey Ten (Lynn) wrote:

I've keep `security.sandbox.content.level` to 4, but whitelisted fontconfig caches
```
user_pref("security.sandbox.content.read_path_whitelist", "/var/cache/fontconfig/,/home/lynn/.cache/fontconfig/");
```

Now `touch ~/.local/share/fonts/` doesn't make firefox to eat 100% of
CPU.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/46

------------------------------------------------------------------------
On 2020-04-08T09:26:41+00:00 Jfkthame wrote:

According to comment 44, it looks like the problem here arises because
the sandbox is blocking fontconfig from reading its caches (which then
results in it doing a full rescan in each process).

So if we add these cache dirs to the sandbox policy, it may help with
this issue.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/47

------------------------------------------------------------------------
On 2020-04-08T09:28:48+00:00 Jfkthame wrote:

Created attachment 9139105
Bug 1495900 - Add fontconfig cache directories to content-process sandbox read paths. r=jld

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/48

------------------------------------------------------------------------
On 2020-04-08T21:17:46+00:00 Hikezoe-birchill wrote:

(In reply to Alexey Ten (Lynn) from comment #44)
> I've keep `security.sandbox.content.level` to 4, but whitelisted fontconfig caches
> ```
> user_pref("security.sandbox.content.read_path_whitelist", "/var/cache/fontconfig/,/home/lynn/.cache/fontconfig/");
> ```
> 
> Now `touch ~/.local/share/fonts/` doesn't make firefox to eat 100% of CPU.

FWIW, with the pref value (though I used my home directory) Firefox
crashes when a wpt finished running on my environment.

bp-8fcb3fe8-6515-4444-8d06-792780200408

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/49

------------------------------------------------------------------------
On 2020-04-08T21:49:46+00:00 Jfkthame wrote:

> FWIW, with the pref value (though I used my home directory) Firefox
crashes when a wpt finished running on my environment.

Huh, that's a bit worrying..... it looks a bit like bug 1627605, but
that only applies when `gfx.e10s.font-list.shared` is enabled, which I
don't see in your crash report. Setting needinfo? to remind myself to
see if I can reproduce that locally.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/50

------------------------------------------------------------------------
On 2020-04-08T23:42:46+00:00 Hikezoe-birchill wrote:

Hmm I don't recall when I set gfx.e10s.font-list.shared to false and re-
set to true, but today I can't reproduce the crash so far, I think I am
using a nightly which is not yet including bug 1627605.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/51

------------------------------------------------------------------------
On 2020-04-09T12:17:44+00:00 Release-mgmt-account-bot wrote:

[Bugbug](https://github.com/mozilla/bugbug/) thinks this bug is a
regression, but please revert this change in case of error.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/52

------------------------------------------------------------------------
On 2020-04-11T09:08:50+00:00 Pulsebot wrote:

Pushed by jkew at mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a58f96ac7e03
Add fontconfig cache directories to content-process sandbox read paths. r=jld

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/53

------------------------------------------------------------------------
On 2020-04-11T21:53:45+00:00 Btara wrote:

https://hg.mozilla.org/mozilla-central/rev/a58f96ac7e03

Reply at:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1870827/comments/54


** Changed in: firefox
       Status: Unknown => Fix Released

** Changed in: firefox
   Importance: Unknown => Medium

-- 
You received this bug notification because you are a member of Mozilla
Bugs, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1870827

Title:
  Firefox hangs after simultaneously opening Chrome/Electron-based
  applications

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/1870827/+subscriptions



More information about the Ubuntu-mozillateam-bugs mailing list