No idea if this is anything to do with it, but this morning I seem unable to run master. I am getting a crash in line 226 of _startBackgroundTask in GCDWebServer.m. EXC_BAD_ACCESS(code=50)
On 9 November 2015 at 08:46, 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
