Blank map after background location update

[1ec5]

#1821 fixes #1460 in that background location updates no longer crash the app in the background. However, it introduces a serious regression in its stead: manually opening the app past that point causes it to launch with a blank, totally black map that you can't interact with until you switch out and back into it with the app switcher.

Opening the app apparently causes it to be revived from the suspended state, and for some reason MGLView is either failing to receive the entered-foreground notification or is bailing because the application state is still "background", not even "inactive".

This behavior is worse than before, because system would automatically relaunch the process if it crashed in the background. Now you just get a defective view.

/cc @incanus @friedbunny

[1ec5]

[1ec5]

When an app is launched in the background (whether due to a location update, fetch update, etc.) and the user then opens the app while it’s suspended, the process receives the usual UIApplicationWillEnterForegroundNotification and UIApplicationDidBecomeActiveNotification. applicationState is UIApplicationStateBackground for the former notification (hence “will”) and UIApplicationStateActive for the latter (hence “did”). This is no different than what happens in a normal launch.

[1ec5]

I don’t know if it’s related, but whenever I attempt to simulate a background launch via Xcode’s “Launch due to background fetch event” setting (with an app that has background fetches enabled), I hit the following shader error and downstream mbgl exception:

[ERROR] {Map}[Shader]: Vertex shader plain failed to compile: precision highp float;
attribute vec2 a_pos;

uniform mat4 u_matrix;

void main() {
    gl_Position = u_matrix * vec4(a_pos, 0, 1);
}
libc++abi.dylib: terminating with uncaught exception of type mbgl::util::ShaderException: Vertex shader plain failed to compile

with this stack:

#8  0x0000000195b81060 in std::rethrow_exception(std::exception_ptr) ()
#9  0x00000001003e1c7c in std::__1::__assoc_state<mbgl::MapContext::RenderResult>::move() at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:681
#10 0x00000001003dc3ac in std::__1::future<mbgl::MapContext::RenderResult>::get() [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:1159
#11 0x00000001003dc39c in mbgl::MapContext::RenderResult mbgl::util::Thread<mbgl::MapContext>::invokeSync<mbgl::MapContext::RenderResult, mbgl::MapContext::RenderResult (mbgl::MapContext::*)(mbgl::TransformState const&, mbgl::FrameData const&), mbgl::TransformState const, mbgl::FrameData>(mbgl::MapContext::RenderResult (mbgl::MapContext::*)(mbgl::TransformState const&, mbgl::FrameData const&), mbgl::TransformState const&&, mbgl::FrameData&&) at /path/to/gl-native/src/mbgl/util/thread.hpp:51
#12 0x00000001003d9e14 in mbgl::Map::renderSync() at /path/to/gl-native/src/mbgl/map/map.cpp:58
#13 0x0000000100484714 in -[MGLMapView glkView:drawInRect:] at /path/to/gl-native/platform/ios/MGLMapView.mm:720
#14 0x00000001857c00f0 in -[GLKView _display:] ()

This causes the app to crash. However, in the wild, when we run into this issue, the app does not crash; it remains usable except that tiles and annotations never render.

[mb12]

You can reproduce similar crash consistently on a real device using the steps below (Press home button before app completes launch). I wouldn't consider this scenario a real issue (not waiting before app finishes launching).

1.) Launch app for debugging in xcode.
2.) Press the home button after the black launch screen appears but before the map loads.

[1ec5]

Hm, I don’t run into that crash when performing those steps, @mb12, with or without the fix for #1821. However, I’m willing to believe that it’s a red herring. I’m just having a difficult time creating a debugging environment that doesn’t involve hopping on Caltrain.

[mb12]

You would have to press the home screen button after you see the black launch screen but before the map appears.

[1ec5]

The shader exception is probably timing related, but that doesn’t do it on my phone at least. We did see it once in field testing in an internal app that includes #1821, but not nearly with the frequency that we used to see the background crash.