IssueTracker

Yes, it memory leak!

When you wanna fix it?

Gotta clean up the DOM and leave it like you found it. :)

I'm creating a mobile app and want to preserve as much memory as possible so keeping a maps instance in memory isn't ideal.

Every time the map is created and destroyed it leaves around 1000 DOM node elements in memory, even if the map is in an iframe and that iframe is destroyed.

Surprised this is still a thing, it's the only major memory leak left in an app I'm working on.

This is a problem for our single page web app. I've resorted to reusing the same map element on every page, adding and removing it from the DOM as necessary.

definitely a memory leak here. I've actually managed to find a semi-workable fix by manually destroying a lot of the elements that google maps creates (and removing listeners). However, I am using a lot of undocumented things to do this (I had to check in the chrome inspector to see what to try to remove), so this doesn't seem the right way to go.

If there will be no ffx, is there an official workaround? (I am also developing a single page web app).

Attempt to find a workaround:

http://stackoverflow.com/q/21142483/684229

Use the below when destroy will free some memory, but not all.
google.maps.event.clearInstanceListeners(window);
google.maps.event.clearInstanceListeners(document);
google.maps.event.clearInstanceListeners(mapDiv);

Use the below when destroy will free some memory, but not all.
google.maps.event.clearInstanceListeners(window);
google.maps.event.clearInstanceListeners(document);
google.maps.event.clearInstanceListeners(mapDiv);

Found the other leak, but I have NO WAY to free it.
It seems that in "common", gmap attach Listener for "resize"/"scroll" directly by window.addeventlistener/window.attachevent(NOT google.maps.event.addDomListener), and the Closure saves too too much vars in its context.

And is there anyway for clean window._xdc_ (maybe js load callback?) by API

has there been any progress with this issue or is it a "low priority". with client-side js frameworks the rage these days, it really makes sense to be able to destroy a map instance after creation.

To work around this problem, I've been re-using the same google map instance throughout all sections of our single page web app.

I just remove it from the DOM and re-add it to a different section.

All my pages implement a dispose method that cleans the map up to it's original state, i.e. remove all markers polygons, restore map options etc.

After moving the map element make sure you fire the 'resize' event so maps redraws itself at the correct size.

Can the google maps developers please give an update on this issue?  Thanks

We're working a project for one of the best bloggers in PL: http://podrozniccy.com
And we have a lot of problems because of that. On one page we need to put 10 photospheres based on google maps API, and it consumes too much RAM (about 60MB per ONE photosphere, which equal more than 600MB for this site).

We've been trying some solutions:
https://gist.github.com/emendelski/e9109674a4cec632d3d6
Do you sth we can correct to minimize RAM consumption?

And dear Google, can you finally update this issue?

I am deeply concerned that this issue hasn't been solved yet.

PLEASE solve this problem. I've been forced to switch to BING maps, until the memory leak problem on Google Map is solved.

[Comment deleted]

Same issue here, but my map is using up 4mb each time! Come'on Google I am too thinking of switching to Bing maps because on cell phone this just blows me up!

I am also facing same issue as I am creating single page application via angular js. This issue may need more attention as going ahead many SPA application developers will face this issue. thanks to the workarounds above. For now, i will t work around this problem, by re-using the same google map instance throughout all sections of our single page web app.

Two years? Looks like google wants us to reuse the same map. So be it.

[Comment deleted]

[Comment deleted]

Just re-use the same map instance, it's not that big a deal...

I wish I had found this thread before putting time into using google maps for this. I am attempting to add markers and remove them based on real time data. I add and remove up to 1200 per minute. The leak kills Chrome after ~8 minutes.

Adding and removing markers doesn't leak. Destroying map does.

FWIW, I gave up on them ever fixing this issue and switched over to Leaflet:

http://leafletjs.com/

Leaflet's API patterns are similar to the Google's, so the switch wasn't too difficult, and I was much happier with the result.

[Comment deleted]

Hi everyone,

First, apologies that we've been silent on this issue up to now.

Next, there's an easy work around, which is to reuse your Map instances. If there's a good reason why you can't do this I'd love to know.

I'm labeling this as won't fix, because this is technically difficult. We're not really sure in how many places we're leaking :-(
Additionally, we'd probably need to introduce some sort of map.destroy() method. Otherwise, how are we to know whether you're planning to reuse the map? Javascript doesn't have destructors, so we can't know you've thrown away your reference to the object.

Sorry to be the bearer of bad news.

Having written a number of single page applications which use Google maps, I have yet to encounter a situation where I couldn't maintain a single map instance that was reused - even if the map view is hidden from the application and later revisited.

However, in multiple cases this technique required significant refactoring and much more complex code to achieve.

That sounds about right...

Was it complicated because you have to reuse the map div? Or some other reason?

Because you have to reuse the map div. Where normally you might create and destory a view every time it is activated and left, you now must keep some type of state (namely the map div and the google.maps.Map object reference) after the view is "destroyed".

I have a hybrid web/native mobile application that pushes/pops views on a stack as the user navigates through a hierarchical dataset.  Each view can potentially contain a map depending on the data.  This means that the app can have N live maps belonging to N views on the view stack.

I suppose I could have maintained a pool of reusable map instances,  but that sounds like a bad idea, especially considering that there are alternative mapping frameworks out there that *do* support a map.destroy() that makes it easy to create/dispose instances.  

(I'm not hating on Google here.  It's perfectly acceptable that Google's API wasn't designed for my use case)

Unbelievable... from 2012 many people ask thins functionalities and at the middle of year 2015 google developers was not able to creare any kind of destroy object ..

Reaction on
https://code.google.com/p/gmaps-api-issues/issues/detail?id=3803#c32

Reason for destroying instance is due to need of change language in single-page-aplication.

As far as I know, only way to change language is re-instatiate instance of Google Maps.

Is this reason enough?

Unfortunately you cannot change language. The language is specified on the bootstrap. If you instantiate two maps, they will share the same bootstrap. So it's not possible to change language in between, as the specified language on the original bootstrap will hold. Loading the boostrap multiple times on the same page is very unsupported behavior, and frankly I don't know what will happen now, or in the future.

The iframe solution mentioned should work, as long as the bootstrap is also loaded in that iframe. That also allows you to switch language, as you can destroy the iframe, recreate a new one, reload a new bootstrap with a new language in the new iframe.

Unbelievable, even open source leaflet has destroy() functionality. I am writing application in ExtJS framework which has dynamic view creation and destroy functionality. Every view is created when it is need by user. When user close view, it is destroyed to free memory. Now I have to rewrite application because using multiple maps cause Internet Explorer process to grow to 1GB and freeze.
More over whole app can open multiple instances of specific view (edit different user) which has map. This leads to taking 30MB for each view, which is latter not freed. Only solution is rewrite every part of app which is using map to single view instance. We have 2015 not 1995, and multi instance view are very common.

Agrh GOOGLE! NOT YOU AGAIN!

i'm not able to find any official documentation about this discussion, only comments.. bah.. desctructor are at the base of any good programming architecture...

I'm currently working on angular app and I cannot reuse the existing map reference because appending the map div in a dialog gives empty grayed map as appears in the attached pic.

Re #44: greyed out map - try triggering a map resize after appending the map div:

google.maps.event.trigger(maphandle,'resize');

[Comment deleted]

Re #45: thanks to your reply. It works only if the init method is surrounded by $timeout or $document.ready.

cheers

Re #47: Glad you got it working :)

I am also facing the same issue for reusing the map as mentioned in #44,Tried the event 'resize', Still my map is blank.
Any sample example would be recommeneded for reusability of map Instance

http://jsfiddle.net/jsfiddleauto/ty3PY/397/, Is any body will guide on this for reusability of mapObject

You need remove the event listeners attached to DOM objects.  Like this http://jsfiddle.net/KWf4r/15/

Here are all of the objects I've found that retain a map on a webpage I looked at (using Maps API V3):

* window 'scroll' listener
* window 'blur' listener
  * Also stored in window.__e3_.blur
* window 'resize' listener
  * Most stored in property window.__e3_.resize
  * One is *not* stored in window.__e3_.resize!
* document 'click' listener
  * Also stored in property document.__e3_.click
* document 'keydown' listener
  * Also stored in property document.__e3_.keydown
* document 'keypress' listener
  * Also stored in document.__e3_.keypress
* document 'keyup' listener
  * Also stored in property document.__e3_.keyup
* document 'MSFullscreenChange' listener
  * Also stored in property document.__e3_.MSFullscreenChange
* document 'fullscreenchange' listener
  * Also stored in property document.__e3_.fullscreenchange
* document 'mozfullscreenchange' listener
  * Also stored in property document.__e3_.mozfullscreenchange
* document 'webkitfullscreenchange' listener
  * Also stored in property document.__e3_.webkitfullscreenchange

Once all of those are cleared, the map is freed. Miss any one of those, and the map is retained. The 'scroll' and 'resize' listeners are the most tricky. Without changing the source code of Google Maps, you'll have to shim addEventListener so you can stash a reference to the listeners for removal later.

EDIT: Updated code to fix a critical bug.

I do, but it's somewhat troublesome! The following should remove all listeners for all maps on the webpage. Removing one map of many on a webpage would be more complicated, and may require Google to actually fix this memory leak with a proper 'destroy' method. :(

By the way, if Google is listening, I can provide stack traces into the minified library that point to the exact source code locations that add these listeners. Just let me know! These traces won't be useful to people using the Maps SDK, since we can't change its code.

Note that if Google updates the Google Maps SDK, then the __e3_ property may be named something different and you will need to adjust the code -- __e3_ seems to be an autogenerated name during minification.

You should double check that the following code fixes the leak. I haven't rigorously tested it yet -- I used a slightly different fix in my own testing for scientific purposes that doesn't make sense in a production environment. (I found & diagnosed this memory leak automatically using a tool I developed.)

// Helper function: Removes all event listeners registered with Google's addDomListener function,
// including from __e3_ properties on target objects.
function removeAllGoogleListeners(target, event) {
  var listeners = target['__e3_'];
  if (!listeners) {
    console.warn("Couldn't find property __e3_ containing Google Maps listeners. Perhaps Google updated the Maps SDK?");
    return;
  }
  var evListeners = listeners[event];
  if (evListeners) {
    for (var key in evListeners) {
      if (evListeners.hasOwnProperty(key)) {
        google.maps.event.removeListener(evListeners[key]);
      }
    }
  }
}

// Removes all DOM listeners for the given target and event.
function removeAllDOMListeners(target, event) {
  var listeners = target['__listeners_'];
  if (!listeners) { return; }
  // Copy to avoid iterating over array that we mutate via removeEventListener
  var copy = listeners.slice(0);
  for (var i = 0; i < copy.length; i++) {
    target.removeEventListener(event, copy[i]);
  }
}

// Shim addEventListener to capture and store registered event listeners.
var addEventListener = EventTarget.prototype.addEventListener;
EventTarget.prototype.addEventListener = function() {
  var eventName = arguments[0];
  var listener = arguments[1];
  if (!this['__listeners_']) {
    this.__listeners_ = {};
  }
  var listeners = this.__listeners_;
  if (!listeners[eventName]) {
    listeners[eventName] = [];
  }
  listeners[eventName].push(listener);
  return addEventListener.apply(this, arguments);
};
var removeEventListener = EventTarget.prototype.removeEventListener;
EventTarget.prototype.removeEventListener = function() {
  var eventName = arguments[0];
  var listener = arguments[1];
  if (this['__listeners_'] && this.__listeners_[eventName]) {
    // Loop because the same listener may be added twice with different
    // options, and because our simple addEventListener shim doesn't
    // check for duplicates.
    while (true) {
      var i = this.__listeners_[eventName].indexOf(listener);
      if (i === -1) {
        break;
      }
      this.__listeners_[eventName].splice(i, 1);
    }
  }
  return removeEventListener.apply(this, arguments);
};

// After you remove the Google Map from the DOM, call this function to completely free the object.
function destroyGoogleMaps() {
  removeAllGoogleListeners(window, 'blur');
  removeAllGoogleListeners(window, 'resize');
  removeAllGoogleListeners(document, 'click');
  removeAllGoogleListeners(document, 'keydown');
  removeAllGoogleListeners(document, 'keypress');
  removeAllGoogleListeners(document, 'keyup');
  removeAllGoogleListeners(document, 'MSFullscreenChange');
  removeAllGoogleListeners(document, 'fullscreenchange');
  removeAllGoogleListeners(document, 'mozfullscreenchange');
  removeAllGoogleListeners(document, 'webkitfullscreenchange');
  // ASSUMPTION: No other library registers global resize and scroll event listeners! If this is not true, then you'll need to add logic to avoid removing these.
  removeAllDOMListeners(window, 'resize');
  removeAllDOMListeners(window, 'scroll');
}



Hope that helps! Let me know if it gives you trouble or misses something.

It's incredible to me that we are facing this problem, especially with SPAs growing in popularity, How/why has this gone unaddressed for almost 10 years?

If Google ever revisits this issue, the automatic memory leak debugger that I've written and used to diagnose this memory leak, BLeak, is now open source and publicly available. It makes it very easy to find the root causes of this memory leak (which are many; I listed them in my previous comment):

http://bleak-detector.org/

I think this bug is now feasible to fix given all of the information supplied, so long as Google is willing to add a `dispose()` method to the API.

I did by the way use your suggestion and I made a few changes, but it works for me right now. Thanks.

I am reusing maps in a single-page app, but I still see the memory leak issue as I navigate between pages that have maps. If I use the destroyGoogleMaps method and shims above, the memory leak issue is solved, but I have other dependencies that register resize events. Does anyone know how I can specifically target only those events registered on the window by google maps? I've already looked at the events in the dev console, but I'm not sure what property I could reliably count on to identify the correct events.

I am still facing issue and It is showing issue of TypeError: null is not an object (evaluating 'e.lineJoin="round"') and TypeError: null is not an object (evaluating 'a.scale')  when I zoom in/out map or I try to create marker and polyline on map. Which listener do I need to remove to fix my issue and memory consumption? I am having IONIC application.

It's real shame that even after Angular 2 (SPA framework) they didn't fix this.

I am seeing this error too on 3.34
null is not an object (evaluating 'a.scale')

7 years passed by, yet no solution.
Having in mind modern SPAs, where map could be used only on one small "contacts" page - thats unbearable.

Google: champions PWA and SPA, supports numerous frameworks including Anglular, Polymer/Lit and AMP, pushes for new features like Shadow DOM, web components, background workers and Web Assembly.

Also Google: "nah, maps shouldn't support any of that. It needs to work in IE6, nobody cares about cool stuff in Google Chrome 71"

No offence meant, but Chrome has moved the goalposts and you have to revisit this in 2019.

Addressing the reasons you've given why this is _Won't Fix_

> "Next, there's an easy work around, which is to reuse your Map instances. If there's a good reason why you can't do this I'd love to know."

I'm using web components and shadow DOM - they don't mean I _can't_ do this, but they make reusing chunks of connected up DOM like this an absolute pain. Additional bugs (mostly thanks to Maps API assuming that any CSS it adds to the document <head> will apply, like #122064478) mean the shadow DOM components that the map's parent element is being moved between all need to apply various bug workaround styles.

This bug significantly increases my maintenance costs for using the (already expensive) maps. Being able to workaround a bug doesn't make it OK to leave that bug unresolved for 8 years.

> "I'm labeling this as won't fix, because this is technically difficult. We're not really sure in how many places we're leaking :-("

That's... worrying. Also: you're Google, and this API is making you many millions, are you seriously saying your technical debt is so expensive that you can't fix it?

> "Additionally, we'd probably need to introduce some sort of map.destroy() method. Otherwise, how are we to know whether you're planning to reuse the map?"

Yup, that's what I'd expect as a bare minimum. Do that.

> "Javascript doesn't have destructors, so we can't know you've thrown away your reference to the object. "

Web components do. Even if they didn't we could tidy this up on routing SPA calls if we had a `map.destroy()` method of some kind.

You have some amazing developers and developer advocates who have build amazing things with the modern web tech like PWAs, web components and background workers, maybe get some of them to look at this problem?

Using google maps with angular seriously hurt it's capabilities... sad. Please fix it

Hi guys, Comment #62 is pretty obvious for me too, all good libraries has destroy methods, all web frameworks has "destroy" hooks

You say "What the problem to reuse map instrances?"

We answer "What the problem collect all the listeners and clear them on destroy?" Refactor once, write unit|e2e test to check memory leak after destroy, and safe live to millions

Eventually  We pay you for usage of this map

Thank you all for your patience. A lot of work has gone into reducing the leaks, and these improvements are included from version 3.38.1 onwards.

Hi poremba.michal, for tracking purposes, can you open a new bug specific to trafficLayer? (It gets confusing if we reopen the same bug for each new memory leak that's found.)
Thanks!

Hey, can I ask what is the status of this bug? It says "Status: Fixed" but "In Prod: false" and I'm getting memory issues in my app after creating google maps instances.

This issue still persist as the create and destroy the instance of map.

sad,  still

lol, they've been deleting my comments for 13 years! 13!!! Let that sink in.

Well... here...we....are...

"13 years later. Rip"