1329826 - 6.0 RC crashes shortly after startup, probably during syncing

Status: RESOLVED INVALID

(Firefox for iOS :: General, defect)

Description

[Matthew N. [:MattN]]

Attachment: Device log from startup until crashing (pid=1561)

+++ This bug was initially created as a clone of Bug #1323045 +++

App Version 6.0 (9) from TestFlight
iPhone 6 running iOS 10.2 (14C92)

I get what looks like a crash less than 15 seconds after startup but I don't get a crash report which I think is related to:
> ReportCrash(CrashReporterSupport)[1565] <Notice>: report not saved because it is non-actionable

This started during the Hawaii All Hands in December and has continued through newer builds on TestFlight.

I don't get a crash if I launch the application in Airplane Mode but otherwise it's reproducible 100% of the time I think.

I think the relevant PID for org.mozilla.ios.FirefoxBeta (Client) is 1561 in the logs.

Comment 1

[Stephan Leroux [:sleroux]]

Sounds similar to the previously reported crashes (I see you already add this bug as See Also on that one).

From the previous discussion, we found two potential causes of the crash - one of which would not produce a crash log so that might be a thread to pull here. If the app gets terminated because of a memory issue, the device won't produce a crash stack but stores a JetsameEvent log. You can see if there was a log produced under Settings -> Privacy -> Diagnostics & Usage. They should be named JetsamEvent-YYY-MM-DD.

The running theory that we have is that when your device is syncing any data from FxA, in some cases we buffer the pulled down data in memory before writing it to disk. In cases where you have many many bookmarks/history/logins/etc items, this can cause the memory to blow up. We've added a patch that should have resolved this for history but that might be faulty or another data type is causing this issue. This would explain why you're only seeing this issue when you can connect to the internet as we can't snarf down the FxA data otherwise.

Related, :rnewman filed a bug recently where he noticed all of his FxA data being re-uploaded and downloaded - even after performing an initial sync [1]. You might be encountering this if you've already synced down your data and performed an upgrade to a newer beta version which would further support the memory-blowing-up theory.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1328123

Comment 2

[Aaron Train [:aaronmt]]

Sounds like the crash conditions could be boiled down signing in with a massive profile and having the client crash on initial pulldown.

Comment 3

[Matthew N. [:MattN]]

(In reply to Stephan Leroux [:sleroux] from comment #1)
> Sounds similar to the previously reported crashes (I see you already add
> this bug as See Also on that one).
> 
> From the previous discussion, we found two potential causes of the crash -
> one of which would not produce a crash log so that might be a thread to pull
> here. If the app gets terminated because of a memory issue, the device won't
> produce a crash stack but stores a JetsameEvent log. You can see if there
> was a log produced under Settings -> Privacy -> Diagnostics & Usage. They
> should be named JetsamEvent-YYY-MM-DD.

I do have these logs for each time it crashes and they list Firefox for iOS ("Client") as the largest process.

> The running theory that we have is that when your device is syncing any data
> from FxA, in some cases we buffer the pulled down data in memory before
> writing it to disk. In cases where you have many many
> bookmarks/history/logins/etc items, this can cause the memory to blow up.
> We've added a patch that should have resolved this for history but that
> might be faulty or another data type is causing this issue. This would
> explain why you're only seeing this issue when you can connect to the
> internet as we can't snarf down the FxA data otherwise.
> 
> Related, :rnewman filed a bug recently where he noticed all of his FxA data
> being re-uploaded and downloaded - even after performing an initial sync
> [1]. You might be encountering this if you've already synced down your data
> and performed an upgrade to a newer beta version which would further support
> the memory-blowing-up theory.
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1328123

OK, I've CC'd myself on that bug and will test again after it's fixed. Let me know if you need more info.

Comment 4

[Stephan Leroux [:sleroux]]

I vaguely remember when you were trying out the login manager you were experiencing UI performance issues because of how many logins you had from a test profile. I'm curious - do you have a substantial set of data you're syncing (bookmarks/history/logins)? Sounds like the memory issue is the problem here which leads me to believe:

1. We missed something in the history memory patch
2. There is another memory issue occurring with a different Sync data type (logins/bookmarks/tabs)

Comment 5

[Matthew N. [:MattN]]

(In reply to Stephan Leroux [:sleroux] from comment #4)
> I vaguely remember when you were trying out the login manager you were
> experiencing UI performance issues because of how many logins you had from a
> test profile. I'm curious - do you have a substantial set of data you're
> syncing (bookmarks/history/logins)?

I do have 627 saved logins (which I believe is down from that last bug report) and I use Firefox Nightly as my primary browser on desktop with a profile I've had around 7 years. I think I have somewhere around 3000 bookmarks. I usually have over 800 tabs but I think I'm down to around 200 now.

Comment 6

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

This is a P1 bug without an assignee. 

P1 are bugs which are being worked on for the current release cycle/iteration/sprint. 

If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.