2056004 - Tabs are crashing randomly with Firefox 153

Status: RESOLVED DUPLICATE of bug 2056509

(Firefox :: Tabbed Browser, defect)

Description

[x3x7]

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

Steps to reproduce:

I am building my own browser on a Fedora like Linux system. With the 153.0 version, sometimes, at random, I get a tab crashing. However, if I reload the URL the tab works fine. Not sure what causes this problem. With previous versions (152.0.4 and earlier) there are no such issues.

The browsers were build using gcc 16.1.1.

Actual results:

With the 153.0 version, sometimes, at random, I get a tab crashing when loading an URL.

Expected results:

All the tabs to load fine.

Comment 1

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

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

Comment 2

[x3x7]

Attachment: firefox_tab_crash.png

https://github.com/mpv-player/mpv/issues/12005

Comment 3

[Tom Schuster]

Can you link a few recent crash reports from about:crashes?

Comment 4

[x3x7]

I opened the about:crashes URL but failed with message below:

Hmm. That address doesn’t look right.
Firefox can’t connect to the server at about:crashes

Comment 5

[x3x7]

Attachment: firefox_tab_crash_2.png

New tab crash. This time the browser was build enabling mozilla_crashreporter. Even with this, the crash reports still remain empty. ("No crash reports have been submitted.")

Another thing to mention is that "Restore This Tab" does not function. Works if I input the URL on the address bar and load it again.

Comment 6

[Martin]

I do also see these crashes. I will try to look into it to get some useful crash reports, but the standard log channels do not give much to work with.

Comment 7

[Andreas M. Kirchwitz]

Looks similar to https://bugzilla.mozilla.org/show_bug.cgi?id=2056509

See also: https://bugzilla.redhat.com/show_bug.cgi?id=2503108

(excerpt follows...)

1. Create a bookmark that is going to redirect you, like "http://www.google.com" (yes, http is intentional, not https), and put it in your bookmarks toolbar.
2. Open that bookmark by right-clicking on it and then "Open in New Tab" or "Open in New Window".
3. Google will redirect the tab from http to https.
4. That new tab/window will soft-crash with "Gah. Your tab just crashed." Firefox itself (with all other tabs) keeps running fine.

There's nothing in about:crashes. Verified with a fresh profile, all defaults, no custom modifications. Tab crash always happens.

It also happens sometimes in the current tab, for example when a Google search collects references for the AI overview but that is hard to reproduce because the AI overview and results are always a little different.

The following URL (http instead of https which results in a redirect) should trigger the crash if opened in a new tab/window (or simply use middle mouse button instead of left):

http://bugzilla.redhat.com/show_bug.cgi?id=2503108

Comment 8

[Martin Stránský [:stransky] (ni? me)]

Used IA to investigate, got this results. May it be caused by system NSS?

Root cause: UUID PRNG not re-seeded after process fork

The log proves it:

• Child 230494 generates UUID {90a0dda9-...} via CreateSourceInternal(new UUID) at this=7f2561152580
• Child 230517 generates the exact same UUID {90a0dda9-...} via CreateSourceInternal(new UUID) at the same this=7f2561152580

Same UUID + same heap address = these two processes were forked from a common ancestor (fork server) and the PRNG state was duplicated without re-seeding.

Looking at the code, GenerateUUIDInPlace tries NSS first (PK11_GenerateRandomOnSlot) on the main thread. NSS uses a userspace PRNG (Fortuna). After fork, if the NSS PRNG isn't re-seeded,
both children produce identical UUID sequences.

The OS fallback (getrandom()) would be fork-safe since it's a syscall, but it's only used when NSS isn't available.

Are you using the fork server? You can check with:

Check dom.ipc.forkserver.enable in about:config.

Possible mitigations to test:

1. Disable fork server: set dom.ipc.forkserver.enable to false in about:config
2. Or set env MOZ_FORK_SERVER=0 before launching

Looks like dom.ipc.forkserver.enable does the trick.