limweb / degrafa

Automatically exported from code.google.com/p/degrafa
1 stars 0 forks source link

Degrafa references prevent modules from unloading causing memory leaks #91

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create a Flex application that loads a module.  The module should include a 
Degrafa Surface, GeometryGroup, and a Line.
2. In the application, load the module.
3. Unload the module.

What is the expected output? What do you see instead?
When running in the profiler, I would expect all classes references only by the 
module, and the module itself, to become eligible for garbage collection after 
the module is unloaded and there are no other references to the module or 
objects within it.  However, when the module includes these Degrafa components 
this does not happen - the instance count of the module and the Degrafa classes 
remains non-zero.

What version of the product are you using? On what operating system?
Tested with both Degrafa 3.1beta and the HEAD revision of 
branches/Origin/Degrafa.  Tested in Mac OS X 10.6.

Please provide any additional information below.
A quick analysis of the degrafa code showed two possible areas where references 
could be held on to.  First, there are static properties of classes (such as 
CommandStack) which reference object instances.  If these are never set to null 
then these objects would never be eligible for GC.  Second, not all event 
listeners were added with weak references or removed.  

I took a stab at implementing a IGCable interface in a few classes that would 
address these issues. I've attached a patch against the Origin branch which 
solves the reference issue for me.  I likely did NOT catch every place where 
this type of work would need to be done.  

Here's an example of how its used in my mxml application:

    <degrafa:Surface x="0" y="0" id="_surface">
           ... stuff
        </degrafa:Surface>

protected function dispose():void {
    _surface.gc();
    _surface = null;
    removeAllChildren();
}

Original issue reported on code.google.com by red5u...@gmail.com on 1 Jul 2010 at 6:20

GoogleCodeExporter commented 9 years ago
Attaching patch

Original comment by red5u...@gmail.com on 1 Jul 2010 at 6:21

Attachments:

GoogleCodeExporter commented 9 years ago
Great work on finding all the different places where flex can hang on to 
references. I am currently trying to implement your patch for degrafa and I 
don't see the IGCable file (which is included/implemented everywhere in your 
patch). Do you happen to have the required file?
Thanks!
~Zach

Original comment by shrodi...@gmail.com on 26 Jul 2010 at 2:41

GoogleCodeExporter commented 9 years ago
Sorry about that - didn't realize the diff left that out.  Attaching IGCable 
(it's a one-method interface).

Original comment by alexz...@gmail.com on 26 Jul 2010 at 5:15

Attachments:

GoogleCodeExporter commented 9 years ago
I was actually gonna just guess I make this file (but I wanted your actual file 
(just in case I missed something). Thank you *so* much for your fast reply!

Original comment by shrodi...@gmail.com on 26 Jul 2010 at 5:17