Firefox loads for a long time when attempting to sync, before crashing

[ericswpark]

Logs

You can help us by sending us either your crash logs or Firefox logs. Instructions on how to do this here. Archive.zip

Zipped up because GitHub doesn't allow .ips files

Steps to reproduce

• Go into synced tabs page
• Pull down to refresh
• Firefox will display the loading spinner on the top (see below). This loading spinner will keep spinning. During this time, Firefox becomes unresponsive, and you cannot switch to anything else (such as tapping on "Tabs" or "Private" next to "Synced") or close out of the dialog entirely with the "Done" button. After about a minute or two of this going on, the actual behavior listed below occurs.

Expected behavior

Syncs tabs and doesn't get unresponsive

Actual behavior

Firefox crashes and returns the user to the springboard

Device & build information

• Device: iPad Pro 12.9 5th-gen
• Build version: Firefox 112.2 (30158)

Notes

This issue does not occur on my iPhone for some reason (14 Pro Max, same build version).

I did encounter some weird behavior from Firefox on my iPhone in the past, so I reinstalled it and it went away. I'm guessing this crash may have something to do with the device not being synced for quite some time. Is there anything in the sync process that could choke on devices that have "drifted" away from the sync data on the Firefox account?

┆Issue is synchronized with this Jira Task

[data-sync-user]

➤ Yoana Rios Diaz commented:

Documenting my findings so far:

• The crash is easy to reproduce opening the Remote/Sync tabs from the SyncTab cell on JumpBack-In section of the homepage on iPad only. Is Watchdog termination crash where the memory and CPU increases until the apps get terminated for the user the UI just frozen.

The crash information provided in this ticket indicates the issue seems to be related to constraints not satisfied on iPad but if we open the TabTray for regular or private tabs and go to the Sync Tabs sections there is no crash.

Option #1 investigate if we are missing any constraint or step when opening directly SyncTabs

Investigating the reload process of the sync tabs we do in some cases 2 different request to get the information removing the call to profile.getClientsAndTabs() (second call to get the tabs info) doesn’t crash the app anymore but breaks the process of getting the latest tabs from other devices so it’s not a viable option.

Option #2 - Not viable right now is to refactor the refresh tabs process to avoid calling the API so often and investigate how this related to the apparent not satisfied constraint crash

[data-sync-user]

➤ Yoana Rios Diaz commented:

I can’t reproduce this issue anymore, moving to QA Needed to verify

[ericswpark]

I can still reproduce this issue on the latest build of Firefox (115.1) on my iPad, but not on my iPhone. Like I said in my initial bug report, I think the client needs to have been offline for an extended period of time, such that it causes the sync process to use too much CPU/memory, getting it killed by the system (oom-killer equivalent or something on iOS?)

I checked the logs after the repro and crash and it looks like the system killed the process after it used too much CPU time:

CPU: 90 seconds cpu time over 94 seconds (96% cpu average), exceeding limit of 50% cpu over 180 seconds

I've attached the full log file below.

Client.cpu_resource-2023-07-25-090850.ips.zip

[lmarceau]

@ericswparkif you don't mind, it would help us if you could share your Firefox logs with us. Let us know if that's possible! Thank you for your time

[ericswpark]

@lmarceau that's the strange part. Other than the Client.cpu_resource-*.ips file, no other crash logs were generated as far as I could tell. I will try the Xcode method and see if I can reproduce the bug.

EDIT: Oh, I didn't know Firefox had a separate log. Sorry! Will post shortly.

[ericswpark]

So the wiki instructions are a bit outdated, or I'm not doing something right. But all I had to do was to use the Files app to send the Firefox log over to my Mac through AirDrop, because Xcode wouldn't list Firefox under the "Installed Apps" section. Maybe this could be added to the wiki? (I don't have edit permission)

Anyway, the file was about 81 MB, so I just extracted a bit, starting from before triggering the crash this morning to a couple hours in after that. Firefox.excpt.log

[lmarceau]

@tarikeshaq would you mind taking a look at the logs and cpu resource files here? This seems to relate to the rust layer 🙏

[ericswpark]

FYI, I had a ton of devices connected/disconnected from Firefox Sync. That might be causing all of the log entries. Also I noticed (when tabs actually synced by going through the Tabs icon) that some devices that I'd already disconnected from Firefox Sync still lingered in the synced tabs section and showed stale tab entries. Might be causing the timeout as it tries to fetch old tabs?

[tarikeshaq]

Hi @ericswpark Thank you so much for getting the logs and I'm sorry you're experiencing this!

It's not clear to me how sync itself could cause the CPU resources we are seeing here, so this might be related to the remote tabs menu itself. Are able to reproduce this issue by tapping Sync Now in your settings menu (Hamburger menu -> Settings -> Sync Now) or does that complete successfully?

Additionally, there are foundational improvements coming to sync in 116 (releasing approx next week) That I hope should fix the problem you're facing!

re: The disconnected devices, that shouldn't be a problem, the logs we are seeing is Sync intentionally filtering out devices that are no longer active

[ericswpark]

Hi @tarikeshaq ,

The Sync Now button in the settings menu completes successfully. The problem only occurs in the remote tabs menu.

In fact, I now have the exact repro steps for it to crash:

• Top right tabs button -> Synced tab -> either pull down to refresh or click "Sync Tabs" -> doesn't crash
• "See all synced tabs" in Firefox Homepage -> goes straight to Synced tab, and freezes. When it freezes, the following is visible:
  • Either no tabs will be shown under the header, or
  • Tabs will be shown, but the favicons won't load in
• If it doesn't freeze, pulling down or refresh freezes it
• After about two minutes or so, the app crashes and drops the user back into the springboard.

Again, this is not reproducible on my iPhone – just my iPad. I'm not sure what the difference is, other than the fact that I've reinstalled the app on iPhone a while ago and maybe that cleared out whatever it is that is causing to crash. Or it could be just a bug that occurs on iPads.

Regarding the disconnected devices, I managed to solve the tabs showing up from disconnected devices by disconnecting and reconnecting my main laptop. My theory on that is that the sync got messed up when I migrated the Firefox installation on my Mac and it caused duplicate entries. To clarify, the freezing problem on the iPad continues even though the duplicate problem has been fixed.

[lmarceau]

I just stumbled on some Xcode warnings that could possibly cause this issue? Xcode detected three different hang risks coming from some Sync Rust code. It's the first time Xcode warns me of those, I think it's worth looking into since I logged in a sync account, and clicked on the sync button from tab tray I believe before getting those.

[tarikeshaq]

Hmm those might be related and we should look into them, given that this hang and crash is only reproducible in the one surface (the remote tab menu) is a hint that it's possible that the surface is doing something with the main thread, when it's supposed to use a background thread there's some evidence in https://github.com/mozilla-mobile/firefox-ios/blob/9c85f82cac29794f3517af8418a94a13fea32f7d/Client/Frontend/Browser/Tabs/RemoteTabs/RemoteTabsPanel.swift#L257

in 116.0 we changed the low-level implementation of the sync manager and the new one should always make sure not to do any work on the main thread

@ericswpark thank you so much for the details! 116.0 is released and rolling out, once you get the chance to upgrade it would be fantastic if you could verify if the hang/crash is fixed or is still there

[ericswpark]

@tarikeshaq updated to version 116.0 (33174) and I can still reproduce the hang and crash.

[joh4nd]

I have a similar problem.

iPad Air 2, ios 15.8.2. The synced tabs are displayed but cannot be entered; Firefox crashes.

An iPhone 7 also running ios 18.8.2 does not crash.

[joh4nd]

On version 124.2 (40108) I can now open sync'ed tabs via the icon on the upper right side of the GUI > switch to syncronized and choosing. It still crashes when trying to enter New Tab > go back to synced tabs via the show all sync'ed tabs.

[joh4nd]

https://github.com/mozilla-mobile/firefox-ios/issues/12067

[ericswpark]

This is still reproducible on Firefox 128.3 (43849).