With regards to implementing a debug menu outside of the app, we can use a settings bundle ( https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/UserDefaults/Preferences/Preferences.html) to create a basic menu screen outside of the app that allows the user to toggle preferences in user defaults that we can check on app launch. For example, we can add an option to clear saved tabs if we thought that is the culprit. Are there any more options we want to be able toggle from outside the app? We could even maybe add a setting to wait to launch the app until Breakpad uploads the previous crash.
On Mon, Nov 9, 2015 at 10:16 AM, Richard Newman <rnew...@mozilla.com> wrote: > That'd be interesting to see, particularly if we can ship a build with > more logging. > > I just filed Bug 1223017 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1223017>, which could be a > culprit. > > > > On Mon, Nov 9, 2015 at 12:46 AM, Lawrence Mandel <lman...@mozilla.com> > wrote: > >> Someone in the Toronto office (maybe Olivier) told me that Firefox for >> iOS became unusable for them due to startup crashes after enabling sync. If >> their phone is still in this state it may be useful for debugging. >> >> Lawrence >> >> On Sun, Nov 8, 2015 at 11:55 PM, Richard Newman <rnew...@mozilla.com> >> wrote: >> >>> Ideas from me. >>> >>> - I've heard that Chrome suffers from something similar. Could this >>> be an OS bug? Can we look through the Chromium bug DB? >>> - Otherwise, early-stage startup >>> (application:willFinishLaunchingWithOptions) includes: >>> - Setting our UA. If we can't get our shared container >>> identifier, for example, then we'll force-unwrap nil. The first time >>> (and >>> after each OS upgrade) we need to create a webview to find the >>> default UA! >>> - Setting up the keyboard helper. Aaron saw this with a stalled >>> splash screen: >>> https://gist.github.com/AaronMT/6ff5e0f5f846755bbd72 >>> - Setting up the file logger. We have a known startup crash: Bug >>> 1218832 <https://bugzilla.mozilla.org/show_bug.cgi?id=1218832>. >>> - Setting up the web server with a fixed port. What happens if >>> that port is taken these days? Can we install a simple test app that >>> collides, and find out? >>> - Touching AVAudioSession. This scares the heck out of me for >>> obvious reasons. >>> - Initing Breakpad itself, which we init at startup; an analog of >>> something like Bug 1218832 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1218832>, but >>> obviously this would deprive us of crash reports… if we have a user >>> who can >>> repro, we could push out a TF/Aurora build that doesn't init >>> Breakpad, see >>> if it fixes things. >>> - If we're worried about opening too many webviews early, can we >>> just delay restore, or open them sequentially, or alter our zombie >>> behavior? >>> >>> >>> On the subject of Sync: there are two aspects to this. >>> >>> One is Sync-related code. That's unlikely to be the culprit: we don't >>> even start the syncing timer until applicationDidBecomeActive, which should >>> be after the splash screen disappears, and that timer doesn't fire until >>> fifteen minutes have elapsed. >>> >>> The other is Sync-related data volumes. There have been a bunch of kinda >>> muddled descriptions of "startup crash". One of them led to the chain of >>> reasoning in Bug 1213623 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1213623>: >>> >>> 1. It's not a crash per se, it's a timeout — we take 20 seconds then we >>> get killed. (That might also take down Springboard if we've consumed a lot >>> of memory before death…) >>> 2. We take 20 seconds replaying the WAL due to a ton of commits that >>> weren't checkpointed. >>> 3. => we should checkpoint more frequently and set sqlite to >>> autocheckpoint more often. >>> >>> Notably this *won't fix things for users who are already wedged*. If >>> your DB is in a state whereby the WAL can't be completely checkpointed >>> within 20 seconds (unlikely, but…), then you'll keep crashing. If we can't >>> find another suspect, then we might consider continuing to look for our car >>> keys under this particular streetlight. >>> >>> On Sun, Nov 8, 2015 at 7:10 PM, Stefan Arentz <sare...@mozilla.com> >>> wrote: >>> >>>> We still have a nasty startup crash that is happening for some people. >>>> Both on 1.0.1 and 1.2. >>>> >>>> (Note that 1.2 is not released yet. We will release 1.1 pretty soon and >>>> 1.2 is ready as a followup bugfix release) >>>> >>>> *This bug will deserves high priority* >>>> >>>> I would like to start a discussion here to figure out what we can do in >>>> terms of debugging this. >>>> >>>> As a refresher, here are some details that we have been able to extract >>>> from testers: >>>> >>>> * The app starts, but does not go past the splash screen >>>> * We have had reports of this for both iPhone and iPad >>>> * People report that the device reboots (the white apple on black >>>> screen happens) - but in reality it is just SpringBoard (the home screen) >>>> restarting >>>> * We have one console log - >>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1220847#c0 >>>> * We do not see this crash in Xcode or in crash-stats >>>> >>>> What did I miss? >>>> >>>> Some thoughts: >>>> >>>> * We need to figure out what code exactly is executed while the splash >>>> screen is visible >>>> * Can we add some verbose logging to the application to find out how >>>> far it progresses before the crash happens? What do we do before it >>>> happens. >>>> * Not sure if this is related to sync - how do we confirm >>>> * Gut feeling says it is related to opening many webviews at startup - >>>> how do we confirm >>>> * In our test builds we can include debugging code and extra UI to help >>>> debug this. Because this is a startup bug, we can also consider to include >>>> system preferences. For example I would like to see a "Close Tabs at >>>> Startup" checkbox there that when flipped removes the tab state restoration >>>> file. That way we can ask people who see this crash to try some things and >>>> see if they get past it. >>>> >>>> All ideas welcome. >>>> >>>> S. >>>> >>>> >>>> _______________________________________________ >>>> mobile-firefox-dev mailing list >>>> mobile-firefox-dev@mozilla.org >>>> https://mail.mozilla.org/listinfo/mobile-firefox-dev >>>> >>>> >>> >>> _______________________________________________ >>> mobile-firefox-dev mailing list >>> mobile-firefox-dev@mozilla.org >>> https://mail.mozilla.org/listinfo/mobile-firefox-dev >>> >>> >> > > _______________________________________________ > mobile-firefox-dev mailing list > mobile-firefox-dev@mozilla.org > https://mail.mozilla.org/listinfo/mobile-firefox-dev > >
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
