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 <[email protected]> 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
> [email protected]
> https://mail.mozilla.org/listinfo/mobile-firefox-dev
>
>
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
