Changes between Version 3 and Version 6 of Ticket #16684


Ignore:
Timestamp:
Feb 7, 2013, 11:35:51 PM (7 years ago)
Author:
Patrick Ruzand
Comment:

What I have found:

  • I thought it was due to the getUID closure that could not be GCed due to the ref to the id string. It's not: extracting the getUID to be a Shape method with a _uid field that is nullified when the shape is detroyed has no effect. That is:

instead of

constructor: function(){
  ...
  var uid = shape.register(this);
  this.getUID = function(){
    return uid;
  }
}

replaced by:

constructor: function(){
  ...
  this._uid = shape.register(this);
},
getUID: function(){
  return this._uid;
},
destroy: function(){
  shape.dispose(this);
  this._uid = null;
}
  • it's not a leak due to the registry map. Even if I comment the call to registry[uid] = shape, the problem still there.
  • The fact that FF or Safari memory is flat (for Safari, it increases then stabilizes) leads me to think the gfx api implementation is handling the cleanup correctly.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #16684

    • Property Cc ben hockey added
    • Property Summary changed from possible gfx MLKs when many shapes are created to possible gfx memory leaks when many shapes are created
  • Ticket #16684 – Description

    v3 v6  
    33The attached sample reproduces the issue. Run it for a long time (1-2h) and monitor the browser memory using a task mgr.
    44
    5 Happens in IE9 (all doc mode) or IE8. This is NOT reproducible on FF.
     5Happens in IE9 (all doc mode) or IE8. This is NOT reproducible on FF or Safari.