Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

Rendered text is garbled when switching styles. #832

Closed
mb12 opened this issue Feb 10, 2015 · 10 comments
Closed

Rendered text is garbled when switching styles. #832

mb12 opened this issue Feb 10, 2015 · 10 comments
Labels
bug iOS Mapbox Maps SDK for iOS
Milestone

Comments

@mb12
Copy link

mb12 commented Feb 10, 2015

I've attached two images with this issue. One image illustrates the garbled text and other image illustrates the expected text.
This reproduces reasonably consistently for me almost everyday. I've seen the garbling happen under two scenarios:

  1. Switching styles (Use sample iosapp and tap to switch styles). This is what I did to take the screenshots.
  2. I've also seen similar garbling when multiple Vector Sources are specified in the same style.json file.

text_corrupted
text_expected

@ljbade ljbade added iOS Mapbox Maps SDK for iOS bug labels Feb 10, 2015
@incanus
Copy link
Contributor

incanus commented Feb 10, 2015

@mb12 Can you give a sample style and coordinate to reproduce this reliably? Haven't seen it. Also, would be handy if you could see if it affects other platforms such as OS X (I would imagine so; this isn't iOS-specific code but could maybe be a GL issue).

@mb12
Copy link
Author

mb12 commented Feb 11, 2015

This may be similar to the original garbled issue I reported (It was happening with single Source. I don't have exact steps to reproduce the garbling in the screenshot I included earlier. ).
With multiple Vector Sources present rendered text looks illegible/garbled as well.

I've included the style.json as well as a screenshot below. The two conflicting layers are "id": "road_major_label" and "id": "road_label". If you remove one or the other, the text is legible.

https://gist.github.com/mb12/7bdcf92c7342e50b66fc

multiple_source

@incanus
Copy link
Contributor

incanus commented Feb 11, 2015

/cc @ansis

@mb12
Copy link
Author

mb12 commented Feb 11, 2015

For the same style.json (the one with multiple sources), I also get random crashes with the following stack trace. (This is for iOS).

Mapbox GL(3561,0x42f1000) malloc: *** error for object 0x19f6b544: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
(lldb) bt
* thread #18: tid = 0x32600, 0x390f1690 libsystem_malloc.dylib`malloc_error_break, name = 'Tile Worker', stop reason = breakpoint 3.1
    frame #0: 0x390f1690 libsystem_malloc.dylib`malloc_error_break
    frame #1: 0x390ef674 libsystem_malloc.dylib`szone_error + 184
    frame #2: 0x390ef978 libsystem_malloc.dylib`free_list_checksum_botch + 28
    frame #3: 0x390e7c30 libsystem_malloc.dylib`tiny_malloc_from_free_list + 212
    frame #4: 0x390e6a70 libsystem_malloc.dylib`szone_malloc_should_clear + 232
    frame #5: 0x390e6954 libsystem_malloc.dylib`malloc_zone_malloc + 72
    frame #6: 0x390e9d32 libsystem_malloc.dylib`malloc + 46
    frame #7: 0x00798746 libglInterpose.dylib`operator new(unsigned long) + 38
    frame #8: 0x001e4d82 Mapbox GL`std::__1::unique_ptr<std::__1::__tree_node<std::__1::__value_type<unsigned int, mbgl::GlyphMetrics>, void*>, std::__1::__map_node_destructor<std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<unsigned int, mbgl::GlyphMetrics>, void*> > > > std::__1::map<unsigned int, mbgl::GlyphMetrics, std::__1::less<unsigned int>, std::__1::allocator<std::__1::pair<unsigned int const, mbgl::GlyphMetrics> > >::__construct_node<unsigned int&, mbgl::GlyphMetrics const&>(unsigned int&&&, mbgl::GlyphMetrics const&&&) [inlined] std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<unsigned int, mbgl::GlyphMetrics>, void*> >::allocate(this=0x17de8560, __n=1, (null)=0x00000000) + 110 at memory:1630
  * frame #9: 0x001e4d64 Mapbox GL`std::__1::unique_ptr<std::__1::__tree_node<std::__1::__value_type<unsigned int, mbgl::GlyphMetrics>, void*>, std::__1::__map_node_destructor<std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<unsigned int, mbgl::GlyphMetrics>, void*> > > > std::__1::map<unsigned int, mbgl::GlyphMetrics, std::__1::less<unsigned int>, std::__1::allocator<std::__1::pair<unsigned int const, mbgl::GlyphMetrics> > >::__construct_node<unsigned int&, mbgl::GlyphMetrics const&>(unsigned int&&&, mbgl::GlyphMetrics const&&&) [inlined] std::__1::allocator_traits<std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<unsigned int, mbgl::GlyphMetrics>, void*> > >::allocate(__a=0x17de8560, this=0x042ee79c, this=0x042eea78, __n=1, __na=0x17de8560, __p=0x042eea78, __d=0x042eea78) + 8 at memory:1435
    frame #10: 0x001e4d5c Mapbox GL`std::__1::unique_ptr<std::__1::__tree_node<std::__1::__value_type<unsigned int, mbgl::GlyphMetrics>, void*>, std::__1::__map_node_destructor<std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<unsigned int, mbgl::GlyphMetrics>, void*> > > > std::__1::map<unsigned int, mbgl::GlyphMetrics, std::__1::less<unsigned int>, std::__1::allocator<std::__1::pair<unsigned int const, mbgl::GlyphMetrics> > >::__construct_node<unsigned int&, mbgl::GlyphMetrics const&>(this=0x17de855c, __a0=0x042eecd0, __a1=0x042eee28) + 72 at map:1330
    frame #11: 0x001db246 Mapbox GL`std::__1::pair<std::__1::__map_iterator<std::__1::__tree_iterator<std::__1::__value_type<unsigned int, mbgl::GlyphMetrics>, std::__1::__tree_node<std::__1::__value_type<unsigned int, mbgl::GlyphMetrics>, void*>*, int> >, bool> std::__1::map<unsigned int, mbgl::GlyphMetrics, std::__1::less<unsigned int>, std::__1::allocator<std::__1::pair<unsigned int const, mbgl::GlyphMetrics> > >::emplace<unsigned int&, mbgl::GlyphMetrics const&>(this=0x17de855c, __args=0x042eecd0, __args=0x042eee28) + 86 at map:1425
    frame #12: 0x001d65d4 Mapbox GL`mbgl::FontStack::insert(this=0x17de8550, id=33, glyph=0x042eee18) + 176 at glyph_store.cpp:21
    frame #13: 0x001d846e Mapbox GL`mbgl::GlyphPBF::parse(this=0x17dbf860, stack=0x17de8550) + 1190 at glyph_store.cpp:213
    frame #14: 0x001d8e26 Mapbox GL`mbgl::GlyphStore::waitForGlyphRanges(this=0x17e3a7cc, fontStack=0x17e69f68, glyphRanges=0x042ef6dc) + 1038 at glyph_store.cpp:261
    frame #15: 0x00134ce0 Mapbox GL`mbgl::SymbolBucket::processFeatures(this=0x17dee1c0, layer=0x19f50ebc, filter=0x17e69ed8, glyphStore=0x17e3a7cc, sprite=0x17e7464c) + 5596 at symbol_bucket.cpp:114
    frame #16: 0x00134eb0 Mapbox GL`mbgl::SymbolBucket::addFeatures(this=0x17dee1c0, layer=0x19f50ebc, filter=0x17e69ed8, id=0x19f68558, spriteAtlas=0x17e3a830, sprite=0x17e7464c, glyphAtlas=0x17e3a740, glyphStore=0x17e3a7cc) + 112 at symbol_bucket.cpp:124
    frame #17: 0x000c7b80 Mapbox GL`mbgl::TileParser::createSymbolBucket(this=0x042f0d6c, layer=0x19f50ebc, filter=0x17e69ed8, symbol=0x17e69f24) + 256 at tile_parser.cpp:264
    frame #18: 0x000c68c8 Mapbox GL`mbgl::TileParser::createBucket(this=0x042f0d6c, bucket_desc=<unavailable>) + 1148 at tile_parser.cpp:210
    frame #19: 0x000c60bc Mapbox GL`mbgl::TileParser::parseStyleLayers(this=0x042f0d6c, group=<unavailable>) + 652 at tile_parser.cpp:81
    frame #20: 0x000c5db0 Mapbox GL`mbgl::TileParser::parse(this=0x042f0d6c) + 140 at tile_parser.cpp:54
    frame #21: 0x001033f8 Mapbox GL`mbgl::VectorTileData::parse(this=0x19f6854c) + 504 at vector_tile_data.cpp:53
    frame #22: 0x000c2748 Mapbox GL`mbgl::TileData::reparse(this=0x17ef6dbc, tile=0x17ef6db0)>)::$_2::operator()(mbgl::util::ptr<mbgl::TileData>&) const + 52 at tile_data.cpp:99
    frame #23: 0x000c2650 Mapbox GL`std::__1::__function::__func<mbgl::TileData::reparse(uv::worker&, std::__1::function<void ()>)::$_2, std::__1::allocator<mbgl::TileData::reparse(uv::worker&, std::__1::function<void ()>)::$_2>, void (mbgl::util::ptr<mbgl::TileData>&)>::operator()(mbgl::util::ptr<mbgl::TileData>&) [inlined] decltype(this=0x17ef6dbc, __f=0x17ef6dbc, __args=0x17ef6db0)>)::$_2&>(fp)(std::__1::forward<mbgl::util::ptr<mbgl::TileData>&>(fp0))) std::__1::__invoke<mbgl::TileData::reparse(uv::worker&, std::__1::function<void ()>)::$_2&, mbgl::util::ptr<mbgl::TileData>&>(mbgl::TileData::reparse(uv::worker&, std::__1::function<void ()>)::$_2&&&, mbgl::util::ptr<mbgl::TileData>&&&) + 16 at __functional_base:413
    frame #24: 0x000c2640 Mapbox GL`std::__1::__function::__func<mbgl::TileData::reparse(this=0x17ef6db8, __arg=0x17ef6db0)>)::$_2, std::__1::allocator<mbgl::TileData::reparse(uv::worker&, std::__1::function<void ()>)::$_2>, void (mbgl::util::ptr<mbgl::TileData>&)>::operator()(mbgl::util::ptr<mbgl::TileData>&) + 48 at functional:1370
    frame #25: 0x000c4ebe Mapbox GL`std::__1::function<void (this=0x17ef6db8, __arg=0x17ef6db0)>::operator()(mbgl::util::ptr<mbgl::TileData>&) const + 158 at functional:1755
    frame #26: 0x000c4da2 Mapbox GL`uv::work<mbgl::util::ptr<mbgl::TileData> >::do_work(data=0x17ef6db0) + 38 at uv_detail.hpp:160
    frame #27: 0x00209fac Mapbox GL`uv__worker_thread_loop(ptr=0x17e58870) + 160 at uv-worker.c:86
    frame #28: 0x0024e91a Mapbox GL`uv__thread_start(ctx_v=0x17e58880) + 46 at uv-common.c:322
    frame #29: 0x39129918 libsystem_pthread.dylib`_pthread_body + 140
    frame #30: 0x3912988a libsystem_pthread.dylib`_pthread_start + 102
(lldb) 

@mb12
Copy link
Author

mb12 commented Feb 11, 2015

Can you please also comment on the following regarding GlyphAtlas in presence of multiple Sources?

GlyphAtlas is maintained per Map, not per Source.
However the following two methods take a tileid only.

GlyphAtlas::addGlyphs
GlyphAtlas::removeGlyphs

Should the tileid passed to these methods be a function of both Tile::ID and SourceInfo?

@incanus incanus modified the milestone: iOS Beta Feb 13, 2015
@bleege
Copy link
Contributor

bleege commented Mar 6, 2015

Determined that the screenshots were from Sunnyvale, CA with coordinates of 37.38533, -122.01727.

@bleege
Copy link
Contributor

bleege commented Mar 6, 2015

Just tested on iPhone 5s Simulator with the latest from master and couldn't reproduce this. Based on gist code above it looks like the original errors where with V6 of the styles while the current code uses V7. I'll test on an actual device to make sure.

ios simulator screen shot mar 6 2015 1 24 37 pm

ios simulator screen shot mar 6 2015 1 25 17 pm

@bleege
Copy link
Contributor

bleege commented Mar 6, 2015

Just ran the same tests on my iPhone 5s using iOS 8.1.3 and the results are consistent with what the simulator showed. I'm going to close this issue for now as it looks resolved to me. If you feel it's not @mb12 please feel free to re-open. Thanks!

img_2120
img_2119

@bleege bleege closed this as completed Mar 6, 2015
@mb12
Copy link
Author

mb12 commented Mar 6, 2015

Thanks for looking into it.

1.) I do see the original garbling issue (first screenshot that I added with this bug) inconsistently when switching styles (I've an older git repo). There are toooooo many issues with Map::start/stop logic that will be addressed by the following. I can verify this once this is merged into master.

#879

2.) Can you please also comment on the correctness of the following?

GlyphAtlas is maintained per Map, not per Source.
However the following two methods take a tileid only.

GlyphAtlas::addGlyphs
GlyphAtlas::removeGlyphs

Should the tileid passed to these methods be a function of both Tile::ID and SourceInfo?

@kkaefer
Copy link
Member

kkaefer commented Mar 6, 2015

@mb12 2) is correct. I opened a ticket for it: #957

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug iOS Mapbox Maps SDK for iOS
Projects
None yet
Development

No branches or pull requests

5 participants