[VKTileKeyMap enumerateKeysAndObjectsUsingBlock:] about mbxmapkit HOT 16 CLOSED

Hi @sunilvignesh,

I think it may be difficult for anyone to respond to this unless you can provide more details about what you were trying to do, what happened, and how that differed from what you were expecting to happen. The VKTileKeyMap stuff looks like it's from Apple's internal implementation of MapKit, and there could be a lot of potential causes.

1. Does the crashing happen with the sample app, or just in your code?
2. If the problem only happens in your code, it would help if you provide sample code to reproduce the problem.
3. If the problem is just with your code, have you checked to make sure that you don't have a concurrency problem such as making UI calls from a background thread?
4. Do you have the same problem with earlier releases of MBXMapKit? If, for example, 0.5.0 works and 0.6.0 crashes consistently, you could look at the commit history to see what changed between 0.5.0 and 0.6.0.

from mbxmapkit.

I am experiencing the same problems when using mbxmapkit in my own app. I think the error happens when a user zooms the map out by pinch zooming. Not sure if it happens when zooming in as well. For me it looks like it it totally random, so on most zooms it does not happen.

from mbxmapkit.

Sounds like from #165 that this could be offline tile-related.

from mbxmapkit.

Can anyone package up a small sample that shows this? I can't repro it locally.

from mbxmapkit.

I can reproduce it with the sample project app from 0.7. Just need to zoom in/out and pan around an offline map you have downloaded (sometimes takes 4-5 minutes, never more than 10 minutes).

The only changes I made to the sample are as follows:

1. line 380 in MBXViewController.m, to download a subset of zoom levels (doesn't cause/eliminate the crash, but seems to speed up its occurrence):

- (IBAction)offlineMapButtonActionBegin:(id)sender 
{
    [[MBXOfflineMapDownloader sharedOfflineMapDownloader] beginDownloadingMapID:_rasterOverlay.mapID mapRegion:_mapView.region minimumZ:14 maximumZ:20];
}

2. commented out line 555 in MBXViewController.m:

- (void)tileOverlay:(MBXRasterTileOverlay *)overlay didLoadMetadata:(NSDictionary *)metadata withError:(NSError *)error
{
    // This delegate callback is for centering the map once the map metadata has been loaded
    //
    if (error)
    {
        NSLog(@"Failed to load metadata for map ID %@ - (%@)", overlay.mapID, error?error:@"");
    }
    else
    {
       // [_mapView mbx_setCenterCoordinate:overlay.center zoomLevel:overlay.centerZoom animated:NO];
    }
}

3. Added these two lines after line 272 in MBXViewController.m:

                _mapView.region = offlineMap.mapRegion;
                _mapView.centerCoordinate = offlineMap.mapRegion.center;

Changes 2 and 3 just help a newly downloaded offline map to show up in a cleaner transition from the previous downloader screen, such that the region and center are loosely the same.

Also, one other data point to add -- if I enable NSZombies, both the sample project and my app crash with the following log entry:

2015-05-18 21:26:52.535 MBXMapKit[2776:1251098] *** -[VKGGLRasterOverlayTile keyPointer]: message sent to deallocated instance 0x134976e00

I want to test a little further to confirm this is only happening with offline tiles, then maybe take a mental pass through the code and try to understand why it might only affect offline tiles. Last time I studied the code months ago, I don't recall seeing a dramatic difference between online/offline other than how the tiles were loaded. You guys might know of other differences behind the scenes.

from mbxmapkit.

I have not been able to confirm this, but my users tell me that this error also happens when using the regular online map. However, it sounds like it happens in areas where the users has been before and thus probably have cached tiles for that area.

from mbxmapkit.

I tried pretty hard to get the online map to crash today, but could not. However offline maps continue to show a crash within 5 minutes of playing with a map. Also see the crash if I play around with an offline map for a couple minutes and then set my device aside. Within a few minutes of inactivity, the same crash will occur with no user input/interaction at all.

from mbxmapkit.

from mbxmapkit.

OK, not sure how much of a clue or help this is, but I noticed that when viewing an offline map, MBXRasterTileOverlay's loadTileAtPath gets called over and over looking for the same missing tiles even when the map is left alone with no interaction. Basically, it seems like any tiles that are not in the offline database, but would be visible in the current region, are being requested over and over. I don't know if this is coming from the MKMapView or your MBXRasterTileRenderer overrides of canDrawMapRect and drawMapRect, but something seems to be causing an endless loop.

Out of curiosity, I inserted some crude code inside MBXRasterTileOverlay's loadTileAtPath where errors are handled after attempting to load a tile from an offline database. When an error is triggered from a URL looking for a tile png, I substitute a blank gray tile image from my app bundle. So instead of seeing MKMapView's beige background or a blurred tile from a lower zoom level where there aren't specific tiles, I now see a gray tile background. This action breaks the endless loop of requesting tiles that aren't in the database, and more importantly, it seems to have eliminated the crashing problem (or at least significantly delayed it, as I have been running my app for 30+ minutes with an offline map and no crash).

Now, if there is something to what I stumbled on, I suspect there is a better fix than the hack I put in. But basically, I think we need a special case when pulling tiles from an offline database; if a tile isn't found in the database, we need to mark it as not present or substitute in another tile so that the MKMapView and/or MBXRasterTileRenderer doesn't keep requesting the tile over and over. I need to study the code in MBXRasterTileRenderer to see if that is a proper location to do this, rather than in MBXRasterTileOverlay's loadTileAtPath. But I can say that interpreting offline tile loading errors in loadTileAtPath is a reasonable way to handle the error in that context.

Hope this helps.

from mbxmapkit.

Very useful @s219. My original thinking was along the lines of offline map tiles being so much faster to fetch that maybe we were exposing a bug or race condition in the VK* framework, but this sounds like a better lead. Particularly because of the tight turnaround allowing for rapid looping like this.

I can't think of a good way to indicate at the overlay level whether tiles are valid or not, so I wonder if simply returning an alpha transparent tile for missing tiles would work? So, your solution @s219 but see-through? Will investigate.

from mbxmapkit.

Can folks give 1c1e6a2 a try? It's simple, but it uses what @s219 figured out to just return a blank image for missing offline tiles. I did in fact see repeated lops of loadTileAtPath without this, but with, things get quiet after the screen is drawn one time. I think this is a pretty promising lead.

from mbxmapkit.

Thanks for working this out more elegantly. 1c1e6a2 is working well for me.

One side effect to this approach (and my hack) is that we no longer see tiles with higher/lower zoom levels linger on screen when zooming/panning around. It's probably not a concern for me, as I was planning to only download a region specified by the user at the current zoom level and higher levels, and then to set the region exactly the same when the offline map is loaded.

from mbxmapkit.

1c1e6a2 also work well for me - another thing I noticed was much much less CPU use. I was getting around 150 -185% CPU running an offline map before this change, now it's small CPU bumps (less than 20%) when panning/zooming.

I also see the same side effect mentioned by s219 - when zooming into higher zoom levels, the map goes blank. I'd prefer the stretched/pixelated lower resolution tile than a blank one at higher zoom levels - but the crashes are gone and the CPU is behaving - which really trumps my concern!

from mbxmapkit.

I'll see what I can do about overzooming tiles — we've done it in other parts of the code, but mostly I wanted to come up with a quick and non-intrusive way to solve the crashing (hopefully) first. It's sounding good.

from mbxmapkit.

See #167 for a revised canDrawMapRect that avoids this crash and fixes another major bug when using 512px tiles. This eliminates the need for the 1c1e6a2 hack.

from mbxmapkit.

@incanus we've seen a high CPU usage with the map sitting still caused by enumerateKeysAndObjectsUsingBlock.

https://cloud.githubusercontent.com/assets/744696/10690437/31653c90-7982-11e5-8794-676d6e92884e.gif

That seems to be fixed with in this pull request. When will it be merged?

Thanks!

from mbxmapkit.