1896398 - File descriptor limit is not loose enough

Status: RESOLVED FIXED

(Core :: IPC, defect, P1)

Description

[leedageea]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0

Steps to reproduce:

OS: Arch Linux
Graphics: Intel Iris Xe (12th Gen)
Desktop Environment: KDE Wayland

1. Open https://www.flightradar24.com
2. Zoom in/out and drag around QUICKLY

Actual results:

The tab crashed. On some circumstances, the whole browser freezes.

Firefox outputs this:

WARNING: failed to create memfd: Too many open files: file /usr/src/debug/firefox/firefox-125.0.3/ipc/chromium/src/base/shared_memory_posix.cc:312

Expected results:

The tab won't crash.

I raised the rlim NOFILE to the hard limit (524288 on my machine) and rerun that tab. It runs without any problem.

strace -e prlimit64 shows that firefox itself raises rlim NOFILE to 4096 by default, which turns out to be not enough.

Relates to Bug 1401776

The limit was hard-coded at https://searchfox.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#3762.

I think we should raise that limit to a much higher one to accommodate some quirky websites.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jld, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

Attachment: Bug 1896398 - Try to increase fd limit to 64k on (non-Apple) Unix.

We're still constrained by any hard limits applied by the distro, but
empirically this is 1024k on Debian/Ubuntu and 512k on Fedora. Older
versions of RHEL may have smaller values; at one point they were known to
use 4k (whence the limit we used before this patch) but I don't know what
the current situation is and the documentation doesn't appear to be public.

64k is probably enough given that a lot of fd usage is shared memory,
and we're usually limited to 64k mappings due to the vma limit (sysctl vm.max_map_count).

This patch does not change the limit for macOS, because we mostly use
Mach shared memory which doesn't use file descriptors.

Comment 4

[:gerard-majax]

should we dupe bug 1885112? It was commented to likely be related to fd exhaustion, and it was also on flightradar i hit it first ...

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/816f57f37d73
Try to increase fd limit to 64k on (non-Apple) Unix. r=glandium

Comment 6

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/816f57f37d73