[core] Tiles that error on load are not renderable

[jfirebaugh]

In 41bbd4e I merged two error pathways that need to be distinct:

• If an error occurs while loading a tile, the tile should not be treated as renderable
• If an error occurs while creating the tile layout, the tile can be considered renderable (there might be partial data, or the data from a prior layout may still be used)

Fixes #6506
Fixes #6547

@halset, thanks for locating the offending commit, it made the cause of this regression easy to find.

[mention-bot]

@jfirebaugh, thanks for your PR! By analyzing the history of the files in this pull request, we identified @kkaefer, @ivovandongen and @brunoabinader to be potential reviewers.

[halset]

Thank you for looking into this, @jfirebaugh! I can confirm that this fixes #6506 and #6547. Looking forward to be back on master again :)

[mikemorris]

LGTM

[kkaefer]

This is crashing tests reliably for me in Debug mode with the following stack trace:

Queue : com.apple.main-thread (serial)
#0  0x00007fffe4aacdda in __pthread_kill ()
#1  0x0000000101cb9a2c in pthread_kill ()
#2  0x00007fffe4a12440 in abort ()
#3  0x00007fffe49d98b3 in __assert_rtn ()
#4  0x0000000100b199f7 in mbgl::util::RunLoop::Get() at platform/darwin/src/run_loop.cpp:19
#5  0x0000000100ab3232 in mbgl::util::WorkQueue::WorkQueue() at src/mbgl/util/work_queue.cpp:9
#6  0x0000000100ab32c5 in mbgl::util::WorkQueue::WorkQueue() at src/mbgl/util/work_queue.cpp:9
#7  0x00000001009942f0 in mbgl::GlyphAtlas::GlyphAtlas(unsigned short, unsigned short, mbgl::FileSource&) at src/mbgl/text/glyph_atlas.cpp:16
#8  0x000000010099498d in mbgl::GlyphAtlas::GlyphAtlas(unsigned short, unsigned short, mbgl::FileSource&) at src/mbgl/text/glyph_atlas.cpp:23
#9  0x00000001009439a0 in std::__1::__unique_if<mbgl::GlyphAtlas>::__unique_single std::__1::make_unique<mbgl::GlyphAtlas, int, int, mbgl::FileSource&>(int&&, int&&, mbgl::FileSource&&&) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:3141
#10 0x0000000100943934 in mbgl::style::Style::Style(mbgl::FileSource&, float) at src/mbgl/style/style.cpp:41
#11 0x00000001009447f7 in mbgl::style::Style::Style(mbgl::FileSource&, float) at src/mbgl/style/style.cpp:44
#12 0x00000001003be29b in RasterTileTest::RasterTileTest() at test/tile/raster_tile.test.cpp:20
#13 0x00000001003bda75 in RasterTileTest::RasterTileTest() at test/tile/raster_tile.test.cpp:14
#14 0x00000001003bd65c in RasterTile_setError_Test::TestBody() at test/tile/raster_tile.test.cpp:36
#15 0x0000000100b10f63 in void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) ()
#16 0x0000000100afbe97 in void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) ()
#17 0x0000000100acbb05 in testing::Test::Run() ()
#18 0x0000000100acd04b in testing::TestInfo::Run() ()
#19 0x0000000100acdce7 in testing::TestCase::Run() ()
#20 0x0000000100adc4c3 in testing::internal::UnitTestImpl::RunAllTests() ()
#21 0x0000000100b14e23 in bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) ()
#22 0x0000000100afe577 in bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) ()
#23 0x0000000100adc0c0 in testing::UnitTest::Run() ()
#24 0x0000000100166c41 in RUN_ALL_TESTS() at mason_packages/osx-x86_64/gtest/1.7.0/include/gtest/gtest.h:20058
#25 0x0000000100166a26 in mbgl::runTests(int, char**) at test/src/mbgl/test/test.cpp:14
#26 0x00000001001577cf in main at test/src/main.cpp:19
#27 0x00007fffe497e255 in start ()

Issue is that while we have a default RunLoop on macOS, it's destroyed whenever you create a new RunLoop.

[jfirebaugh]

Weird, why didn't this fail macOS CI?

[jfirebaugh]

#6423 (comment)