1448844 - Firefox hangs/freezes randomly when loading web pages on Debian

Status: RESOLVED DUPLICATE of bug 1428169

(Core :: DOM: Core & HTML, defect, P2)

Description

[Paul-Antoine Arras]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180317044808

Steps to reproduce:

Load a random web page in a tab.


Actual results:

Sometimes, Firefox hangs/freezes for a variable amount a time: from a couple of seconds up to more than a minute.
The whole browser is hung, not only the current tab. It is not even possible to stop the loading using the cross button. However, the rest of my system stays responsive.
I have not noticed an unusual CPU/memory usage.

This happens even with a clean profile and all add-ons disabled. This happens with both this version from Debian repository and the one from Mozilla. This did not happen with Ubuntu 16.04 on the same computer.



Expected results:

The web page should load (almost) immediately and the browser should stay responsive.

Comment 1

[Paul-Antoine Arras]

Crash report: https://crash-stats.mozilla.com/report/index/88d442db-d96d-40c5-b369-c8d270180326

Comment 2

[Paul-Antoine Arras]

BTW, Firefox never crashes by itself when it's hung. I generated the crash report by sending SIGABRT.

Comment 3

[wrongnumber.fu]

Can confirm, experiencing the same issue. https://bugzilla.mozilla.org/show_bug.cgi?id=1448566 looks similar as well.

Comment 4

[Adrian Florinescu [:aflorinescu]]

Paul, could you also try to record a performance profile while reproducing the problem?  (https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem)

Comment 5

[Paul-Antoine Arras]

(In reply to Adrian Florinescu [:AdrianSV] from comment #4)
> Paul, could you also try to record a performance profile while reproducing
> the problem? 

Sure! Here it is: https://perfht.ml/2GDdPPd
The page loaded was https://drive.google.com

Comment 6

[Adrian Florinescu [:aflorinescu]]

Mike, could you please take a look at the perf. profile from comment 5?

Comment 7

[Mike Conley (:mconley) (:⚙️)]

This looks to me like we're waiting on a PBackgroundStorage::Preload sync IPC message, which I guess is being blocked on the file system on the IO thread.

The profile doesn't show us hanging in the main thread of the parent process, but it's hard for me to make sense of it because it's pseudostacks only (we'd need you folks to use Nightly to give us true native stacks).

Placing this in DOM right now, since there doesn't seem to be a DOM :: Storage component.

Comment 8

[Paul-Antoine Arras]

(In reply to Mike Conley (:mconley) (:⚙️) (Totally backlogged on reviews and needinfos) from comment #7)
> The profile doesn't show us hanging in the main thread of the parent
> process, but it's hard for me to make sense of it because it's pseudostacks
> only (we'd need you folks to use Nightly to give us true native stacks).

Thanks Mike for looking into this.

Would it be helpful if I collected a performance profile with Nightly?

Comment 9

[Adrian Florinescu [:aflorinescu]]

(In reply to Paul-Antoine Arras from comment #8)
> Would it be helpful if I collected a performance profile with Nightly?
Yes, please.

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

Any chance you're using an NFS file-system or some other remote file-system that might have problem with SQLite's default locking semantics?  If so, see https://bugzilla.mozilla.org/show_bug.cgi?id=1428169#c26 for a pref you can flip.  (The bug, bug 1428169 is also basically the same scenario, but known to be NFS.)

Comment 11

[Mike Conley (:mconley) (:⚙️)]

Setting a needinfo? on Paul-Antoine Arras for comment 10.

Comment 12

[Paul-Antoine Arras]

(In reply to Andrew Sutherland [:asuth] from comment #10)
> Any chance you're using an NFS file-system or some other remote file-system
> that might have problem with SQLite's default locking semantics?  If so, see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1428169#c26 for a pref you can
> flip.  (The bug, bug 1428169 is also basically the same scenario, but known
> to be NFS.)

Thank you very much Andrew for the insight!
I've been using Nightly with `storage.nfs_filesystem` set for almost a week without noticing any hang.
I'll continue to monitor the behaviour for a couple of days, and if nothing comes up I think we'll be able to close this one as a dup of bug 1428169.

Comment 13

[Andrew Sutherland [:asuth] (he/him)]

I'm glad to hear that fixes things.  It's sounding like we probably really need to re-visit our use of the pref for NFS.  Any info you could provide about your NFS setup would be invaluable.

In particular:
- The NFS server program and version in use.
- The client program and version in use.
- Any special server settings, client settings, or mount settings.  For example, mount supports "nolock" which sounds appropriately terrifying.
- Does lockd or statd seem broken on the server?  For example, http://sophiedogg.com/lockd-and-statd-nfs-errors/ calls out Firefox experiencing problems after the server's state files seemed to get corrupted.

Thanks for any help you can provide to help us improve Firefox for NFS users!

Comment 14

[Paul-Antoine Arras]

(In reply to Andrew Sutherland [:asuth] from comment #13)
> I'm glad to hear that fixes things.  It's sounding like we probably really
> need to re-visit our use of the pref for NFS.  Any info you could provide
> about your NFS setup would be invaluable.

Sure, the details are inlined below:

> In particular:
> - The NFS server program and version in use.

Unfortunately, I don't think I have access to this info.

> - The client program and version in use.

$ apt show nfs-common      
Package: nfs-common
Version: 1:1.3.4-2.2
Priority: optional
Section: net
Source: nfs-utils
Maintainer: Debian kernel team <[e-mail]>
Installed-Size: 739 kB
Provides: nfs-client
Depends: libc6 (>= 2.15), libcap2 (>= 1:2.10), libcom-err2 (>= 1.01), libdevmapper1.02.1 (>= 2:1.02.97), libevent-2.1-6 (>= 2.1.8-stable), libgssapi-krb5-2 (>= 1.14+dfsg), libk5crypto3 (>= 1.6.dfsg.2), libkeyutils1 (>= 1.5.9), libkrb5-3 (>= 1.6.dfsg.2), libmount1 (>= 2.19.1), libnfsidmap2, libtirpc1 (>= 0.2.4), libwrap0 (>= 7.6-4~), rpcbind, adduser, ucf, lsb-base (>= 1.3-9ubuntu3), keyutils
Recommends: python
Suggests: open-iscsi, watchdog
Conflicts: nfs-client
Breaks: nfs-kernel-server (<< 1:1.2.8-6~)
Replaces: mount (<< 2.13~), nfs-client, nfs-kernel-server (<< 1:1.2.8-6~)
Homepage: http://nfs.sourceforge.net/
Tag: admin::filesystem, implemented-in::c, interface::commandline,
 interface::daemon, network::client, network::server, protocol::nfs,
 role::program
Download-Size: 230 kB
APT-Manual-Installed: no
APT-Sources: http://deb.debian.org/debian unstable/main amd64 Packages
Description: NFS support files common to client and server
 Use this package on any machine that uses NFS, either as client or
 server.  Programs included: lockd, statd, showmount, nfsstat, gssd,
 idmapd and mount.nfs.

> - Any special server settings, client settings, or mount settings.  For
> example, mount supports "nolock" which sounds appropriately terrifying.

$ mount
[...] type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=146.169.1.148,mountvers=3,mountport=46408,mountproto=udp,local_lock=none,addr=146.169.1.148)

> - Does lockd or statd seem broken on the server?  For example,
> http://sophiedogg.com/lockd-and-statd-nfs-errors/ calls out Firefox
> experiencing problems after the server's state files seemed to get corrupted.

Here again, as I don't have full access to the server, I cannot tell.
However, me and other people have been using the same NFS server on different setups without any issue, so I strongly feel it's on the client side.

Comment 15

[Andrew Sutherland [:asuth] (he/him)]

Thanks very much for the info!

Comment 16

[Andrew Sutherland [:asuth] (he/him)]

I'm going to dupe over to the NFS localStorage bug for consolidation, but will explicitly call out the referenced info here.