Yeah I like the idea of 'Debug Prefs' a lot. • Do not restore tabs - Skip tab restoration the next time we start up. • Upload crash reports - Maybe start with a minimal UI that just is there to give Breakpad time • Do not start internal web server • Send logs - Start the app with a mail composer with the logs attached. We must be sure to not overwrite old logs though!
We can't submit this to the app store but I am pretty sure we will be fine if we send this to TestFlight or Aurora testers. S. On Mon, Nov 9, 2015 at 11:49 AM, Steph Leroux <sler...@mozilla.com> wrote: > 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
