Fixed
Status Update
No update yet.
Comments
th...@google.com
I do have found that sometimes, under some "isolated non-obvious" circumstances, some memory is actually freed (see attached image). But I agree with this post, because in general, it seems like no memory is ever freed by Google Maps SDK.
To me, the most important problem here is that the map does not free memory nor even when memory warnings are received, so you can have your app performing really bad at a given moment just because there are tiles in memory from Google Maps SDK that you actually are not seeing in your map view at that moment.
To me, the most important problem here is that the map does not free memory nor even when memory warnings are received, so you can have your app performing really bad at a given moment just because there are tiles in memory from Google Maps SDK that you actually are not seeing in your map view at that moment.
ca...@gmail.com
yes that is it... thanks for the image. it reflects what I see.
lu...@google.com
[Deleted User] <[Deleted User]>
I think a serious problem, for old devices (3GS / 4).
[Deleted User] <[Deleted User]>
Error occurs when too many separate icons (instances of UIImage) are attached to GMSMarkers.
Solution: if multiple markers use the same image, make sure they reference the same object (not multiple instances of the same content).
Solution: if multiple markers use the same image, make sure they reference the same object (not multiple instances of the same content).
ng...@gmail.com
We can also confirm that memory usage keeps going up while new tiles are loaded. Any word on when we can expect a fix?
br...@google.com
I can confirm this behavior; on a (256K RAM) iPod Touch, my app is getting repeated warnings after scrolling/zooming, and eventually, memory-kicked by iOS. Memory is not reclaimed after initial Google Maps use, although no memory leaks show up in Instruments.
eg...@gmail.com
yes, to me it seems like the MOM used for caching tiles just keeps growing without bounds.
so unbounded caching seems to happen -- no leak
so unbounded caching seems to happen -- no leak
jo...@gmail.com
Yes, same for me, when i m zooming allocation memory is increased, after there is memory warning, after app crashes.
da...@porterdigital.com
Same for us.
But for us the leak appear for set marker image. You can easily crash the application if you'll set large images for any markers.
As per call trace analysis it seems that library creates atlas for markers to draw it and never free it.
But for us the leak appear for set marker image. You can easily crash the application if you'll set large images for any markers.
As per call trace analysis it seems that library creates atlas for markers to draw it and never free it.
jo...@gmail.com
yes, I can confirm it crashes for markers too ... :(
li...@gmail.com
This is also happening to Foodspotting.
App launches and settles in at 14mb until the first map view is loaded and finished setup it grows to 90mb. Once the map view is dealloc'd the app returns to 30mb.
App launches and settles in at 14mb until the first map view is loaded and finished setup it grows to 90mb. Once the map view is dealloc'd the app returns to 30mb.
da...@porterdigital.com
how to fix ？
ti...@gmail.com
In 1.5.0, memory usage has been reduced significantly.
br...@google.com
This is definitely not fixed in the 1.5.0 SDK. I can reproduce 100% of the time a situation in which doing all of the following:
[_mapView clear];
[_mapView stopRendering];
_mapView.delegate = nil;
_mapView = nil;
Still results in a huge amount of memory not being released.
Just to be clear, if memory usage is at 14mb when I push a view controller that instantiates GMSMapView, the expectation is that when I release the instance of GMSMapView, memory should return to 14mb fairly quickly.
'Aggressive' cacheing should be optional, especially since in this case it's a guaranteed crash if the user visits this view controller regularly.
[_mapView clear];
[_mapView stopRendering];
_mapView.delegate = nil;
_mapView = nil;
Still results in a huge amount of memory not being released.
Just to be clear, if memory usage is at 14mb when I push a view controller that instantiates GMSMapView, the expectation is that when I release the instance of GMSMapView, memory should return to 14mb fairly quickly.
'Aggressive' cacheing should be optional, especially since in this case it's a guaranteed crash if the user visits this view controller regularly.
sa...@synchsoft.in
Still have same issue with 1.7.2v. Memory doesn't release after destroy mapView. Any suggestion about fixing?
sa...@synchsoft.in
Comment has been deleted.
Description
demonstration page if at all possible, or attach code.
Started with SDK 1.4, perhaps related to "Ghost markers" introduced with the same release (NB! Ghost markers are still here in 1.4.2!!)
1. Extend GMSMarker with custom icon setter in it (fetches and sets icon from remote URLs), animation enabled
2. Create map with 100+ markers
3. Zoom in and out rapidly, redrawing markers at zoom end (remove all markers, cluster, place new annotations on map)
4. Receive "Reached the max number of texture atlases, can not allocate more" fatal error and crash
*********************************************************
For developers viewing this issue: please click the 'star' icon to be
notified of future changes, and to let us know how many of you are
interested in seeing it resolved.
*********************************************************