I'm wondering whether you've tried to chase what is referencing the context?
If you're loading the small games with a Loader, are you using the Loader's unloadAndStop() method? I know there used to be problems with complete unloading of anything containing sound, but I'm sure that has been fixed a long time ago.
I'm sure we can help you find out where the reference is.
Support Staff3 Posted by creynders on 21 Feb, 2012 11:41 AM
My guess is this has nothing to do with RL, but I'm definitely
no expert on RL modules, so it could be I'm wrong.
we dispose of the small game context, and destroy the view that
holds the small game in the main app
but do you unload the module's .swf?I'm guessing that's
what doesn't get GC'd
I can see that cause I have created a static variable in the
modular small game, I increment it each time I create a new
instance of this module, and it keeps going up, so it's deffo using
the same context again.
Doesn't mean that it's using the same context again, just that
the class definition itself has not been removed from memory.
Hey thanks for the so fast reply, I wasn't expecting any thing
before tomorrow hehe.
I have added the unloadAndStop method to my loader, but it
doesn't change any thing.
I have actually access to the Flex Debugger. I am casting the
swf file loaded as a sprite for practical reasons, then i assign it
to a IModule variable to inject the injector of the main swf file.
I properly dispose this IModule variable then assign null to
Maybe something I should have mentionned guys is there's
communication between this module and the main swf file, and
another reason I can see it's using the same context is that at the
beginning I send a request from the game to the main sw file and
when I get the response, I display the state of the game, and it
displays it twice....I checked my game twice and the communication
and it's definitely not sending the response twice.
To reformulate, it's like it's using a new context and the
I am using RL 1.5.2 , and the modular thing...I don't know to be
honest, I will compare joelhooks and Stray zip to mine to see which
one I'm using, then come back to you
Hrm. In that case I'd say the Flex debugger is your best bet. As creyenders pointed out, a static var is a property of the class, not the instance, so that tells you nothing, but I'm assuming that you have other things going on which suggest it's the same instance?
Hehe I know that's a tough one. The lead Flash Developer of
another team where I work tried to look into it with me, but he
cannot find what's going on apart from the context being the same
name and being probably cached some where by RL or Flash
As I said, the communication between the module and the main swf
file can show me that the command catching the response from the
main swf file is called twice with 2 different current state, which
is not happening the first time I run the game :-)
So there's another small game instance living some where.
As I said as well, we have 12 other games, that are actually
Jigsaw games, that are exactly the same, but they have different
We could see that as soon as you had run once, one of this 12
jigsaw game, no matter which one you were choosing the next time,
the first one you had run was always the one on screen, in term of
resources. We checked the URL to be sure we weren't loading the
same one again, and every thing was fine.
However, as soon as we changed the name of the context, so
instead of having 12 JigsawGameContext, we had JigsawGameContext_1,
JigsawGameContext_2, etc.. up to 12, then it was loading the
correct game each time.
I gotta say, those 12 jigsaw games don't hold any state, so I
cannot check if we have the same issue than with this other game in
terms of having more than one running.
Last interesting thing is when I run like 3/4 times the other
game, I can see the command getting the response from the server
called....3/4 times, so it's more like the swfs are staying some
where despite the fact that I unload them and dispose of them
As a diagnostic test, I would make it so that the second time the game is loaded, it does not run the loading code. this will let you find out what is holding the reference to the original loaded version.
There's no reason why Robotlegs itself would be caching it - we all use the modular Robotlegs regularly and don't generally see this problem.
But I'd like to help you fix it - so if you want to zip up your compiled application I can take a look with Monster Debugger?
I'm guessing in the end it'll either be one of the usual suspects (an event listener not being removed, a static reference accidentally kept to a deeply nested member etc) or it may even be a problem with the Flash Loader itself (I've had to implement some workarounds in my project because of Loaders corrupting sometimes).