1975853 - some page not loaded from session restore

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[mix5003]

Attachment: sessionstore.jsonlz4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36

Steps to reproduce:

idk, firefox updated and boom.

i can partial reproduce this issue by use this method

1. create new profile
2. set Open previous windows and tabs = true
3. goto about:config and set these value
   browser.sessionstore.restore_tabs_lazily = false
   browser.sessionstore.restore_on_demand = false
   browser.tabs.fadeOutUnloadedTabs = true (for debug only)
4. close firefox and replcate sessionstore.jsonlz4 with provided files
5. start firefox normally

Actual results:

page not load from session restore. something like this
https://youtu.be/wT1nHdostL0 (google and jira loading forever)

Expected results:

it should not normally

Comment 1

[mix5003]

mozregression said

2025-07-06T13:18:28.415000: DEBUG : Found commit message:
Bug 1964600 - Introduce an IPC channel between child processes and the crash helper r=afranchuk

This channel is currently only used on Linux to rendez-vous with the
crash helper, obtain its PID and use it to enable the process to be
dumped when the Yama LSM is enabled. It will be used to actually request
a dump in the future, when the breakpad exception handler is removed.

Differential Revision: https://phabricator.services.mozilla.com/D254047


2025-07-06T13:18:28.416000: DEBUG : Did not find a branch, checking all integration branches
2025-07-06T13:18:28.421000: INFO : The bisection is done.
2025-07-06T13:19:35.307000: INFO : Stopped

and i found this in mozregression logs

2025-07-06T13:13:57.203000: INFO : b'ConnectToPipe() failure: GetLastError()=00000002'
2025-07-06T13:13:57.203000: INFO : b'ConnectToPipe() failure: GetLastError()=00000002'
2025-07-06T13:13:57.203000: INFO : b'ConnectToPipe() failure: GetLastError()=00000002'
2025-07-06T13:13:57.209000: INFO : b'[Parent 45000, IPC I/O Parent] WARNING: Failed to launch tab subprocess @Could not create an IPC channel to the crash helper (Error:0): file /builds/worker/checkouts/gecko/ipc/glue/GeckoChildProcessHost.cpp:804'
2025-07-06T13:13:57.210000: INFO : b'ConnectToPipe() failure: GetLastError()=00000002'
2025-07-06T13:13:57.215000: INFO : b'[Parent 45000, IPC I/O Parent] WARNING: Failed to launch tab subprocess @Could not create an IPC channel to the crash helper (Error:0): file /builds/worker/checkouts/gecko/ipc/glue/GeckoChildProcessHost.cpp:804'
2025-07-06T13:13:57.216000: INFO : b'ConnectToPipe() failure: GetLastError()=00000002'
2025-07-06T13:14:00.139000: INFO : b'[Parent 45000, IPC I/O Parent] WARNING: Failed to launch tab subprocess @Could not create an IPC channel to the crash helper (Error:0): file /builds/worker/checkouts/gecko/ipc/glue/GeckoChildProcessHost.cpp:804'
2025-07-06T13:14:00.142000: INFO : b'[Parent 45000, IPC I/O Parent] WARNING: Failed to launch tab subprocess @Could not create an IPC channel to the crash helper (Error:0): file /builds/worker/checkouts/gecko/ipc/glue/GeckoChildProcessHost.cpp:804'
2025-07-06T13:14:00.144000: INFO : b'[Parent 45000, IPC I/O Parent] WARNING: Failed to launch tab subprocess @Could not create an IPC channel to the crash helper (Error:0): file /builds/worker/checkouts/gecko/ipc/glue/GeckoChildProcessHost.cpp:804'
2025-07-06T13:14:00.146000: INFO : b'[Parent 45000, IPC I/O Parent] WARNING: Failed to launch tab subprocess @Could not create an IPC channel to the crash helper (Error:0): file /builds/worker/checkouts/gecko/ipc/glue/GeckoChildProcessHost.cpp:804'
2025-07-06T13:14:00.149000: INFO : b'[Parent 45000, IPC I/O Parent] WARNING: Failed to launch tab subprocess @Could not create an IPC channel to the crash helper (Error:0): file /builds/worker/checkouts/gecko/ipc/glue/GeckoChildProcessHost.cpp:804'
2025-07-06T13:14:00.151000: INFO : b'[Parent 45000, IPC I/O Parent] WARNING: Failed to launch tab subprocess @Could not create an IPC channel to the crash helper (Error:0): file /builds/worker/checkouts/gecko/ipc/glue/GeckoChildProcessHost.cpp:804'

Comment 2

[mix5003]

in my main profile (with cookies) it didn't load any tab
may be for some reason sentry has this issue too, so it never pass gmail and sentry

Comment 3

[BugBot [:suhaib / :marco]]

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

Comment 4

[BugBot [:suhaib / :marco]]

:gsvelto, since you are the author of the regressor, bug 1964600, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 5

[mix5003]

i can not reproduce in linux mint.
i think this specific to windows only

Comment 6

[Gabriele Svelto [:gsvelto]]

Is it happening consistently at every launch? Can you check if you can find this file in your home directory AppData\Roaming\Mozilla\Firefox\Crash Reports\crash_helper_server.log? If it's present what does it contain? I don't reproduce locally but I'll try to induce some artificial failures in that code path to see if I can trigger this behavior.

Comment 7

[Gabriele Svelto [:gsvelto]]

Confirming this as I think I found a failure path that could lead to this behavior. I'd still be curious to know what's in the crash_helper_server.log file because this should be a very uncommon situation.

Comment 8

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1964600

Comment 9

[mix5003]

for me it consistently at every launch.

only 1 line in crash_helper_server.log

[ERROR crash_helper_server] The crashhelper encountered an error, exiting (error: Error while waiting for events, error: Some(87))

Comment 10

[Gabriele Svelto [:gsvelto]]

Thank you, this is very useful. I've got a fix coming.

Comment 11

[Gabriele Svelto [:gsvelto]]

Attachment: Bug 1975853 - Fail gracefully if we cannot start the crash helper client r=afranchuk

Before this patch if we failed to launch the crash helper client then we
would either freeze or crash Firefox, which is not what we want. This
makes sure that errors when launching the crash helper are not
catastrophic. Additionally, this problem was triggered on a machine that
launched more than 64 child processes at startup during session restore.
That was a hard limit on Windows because of the limitations of
WaitForMultipleObjects(). I adjusted the code to also handle that
gracefully even though we don't support more than 64 child processes at
the moment. That's not a big deal because we're not yet using that
particular IPC channel, so ignoring every child process above the 63rd
doesn't change anything at the moment. Last but not least there was a
small race in the crash helper rendez-vous that might cause Linux to
attempt to generate a minidump before we had allowed a child process to
allow the crash helper to ptrace() it. This was also fixed.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/7967cfe7a06b
https://hg.mozilla.org/integration/autoland/rev/8e98cdfa2572
Fail gracefully if we cannot start the crash helper client r=afranchuk

Comment 13

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/8e98cdfa2572

Comment 15

[Gabriele Svelto [:gsvelto]]

Attachment: Bug 1975853 - Fail gracefully if we cannot start the crash helper client

Before this patch if we failed to launch the crash helper client then we
would either freeze or crash Firefox, which is not what we want. This
makes sure that errors when launching the crash helper are not
catastrophic. Additionally, this problem was triggered on a machine that
launched more than 64 child processes at startup during session restore.
That was a hard limit on Windows because of the limitations of
WaitForMultipleObjects(). I adjusted the code to also handle that
gracefully even though we don't support more than 64 child processes at
the moment. That's not a big deal because we're not yet using that
particular IPC channel, so ignoring every child process above the 63rd
doesn't change anything at the moment. Last but not least there was a
small race in the crash helper rendez-vous that might cause Linux to
attempt to generate a minidump before we had allowed a child process to
allow the crash helper to ptrace() it. This was also fixed.

Original Revision: https://phabricator.services.mozilla.com/D256299

Comment 16

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Firefox may not launch under certain conditions on both Windows and macOS. Additional patches in this stack fix resource leaks and spurious shutdown crashes on different platforms.
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: -
• Risk associated with taking this patch: medium
• Explanation of risk level: These changes rode the trains and shipped in the release channel so they're known to work at this point, however it's a significant amount of LOCs to be uplifted in one go
• String changes made/needed: none
• Is Android affected?: no

Comment 17

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/e56432f1e2ad