Problem Modular Context Being Cached by Main Application

Christophe's Avatar


21 Feb, 2012 11:04 AM


I am writing here cause I haven't been unable to find a way to fix the problem I have encoutered.

Here is an explanation :

I have a main project using swf file. Then I have small games using RL as well but implemented as Modules. Those small games can be run multiple times, not at the same time, but you get in, you close it, then come back to it 10 sec later.

Here is the issue : Every thing is destroyed properly, we dispose of the small game context, and destroy the view that holds the small game in the main app, but when I trigger the small game later on, like 5 sec later, it's like the main app has cached the small game context and instead of loading a new one (cause the small games swf files are loaded from a server), it's like using the one that is supposed to have been destroyed.

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. I don't want that obviously, and I was wondering if any one had an idea how to fix that ?

I encountered the same issue with another game, this one was duplicated 12 times on the server but with different assets in, but because the contexts were the same names, it was always loading the same one, so we fixed it by using different context names, which led us to create 12 different projects :/

But this time, I can't do it, cause we want the same small game, but each time like you're accessing it for the first time.

Thank you and sorry for my English

  1. 1 Posted by Stray on 21 Feb, 2012 11:38 AM

    Stray's Avatar

    Hi Christophe,

    do you have access to the flex debugger?

    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.

    Which version of modular utilities are you using?



  2. Support Staff 2 Posted by creynders on 21 Feb, 2012 11:41 AM

    creynders's Avatar

    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.

    You write

    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.

  3. 3 Posted by Christophe on 21 Feb, 2012 12:09 PM

    Christophe's Avatar

    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 it.

    m_moduleRef.parentInjector = null;
    m_moduleRef = null

    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 previous one.

    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

  4. 4 Posted by Christophe on 21 Feb, 2012 12:13 PM

    Christophe's Avatar

    I am using the modular utilities from Joel Hooks

  5. 5 Posted by Stray on 21 Feb, 2012 12:39 PM

    Stray's Avatar

    There was an issue with the moduleCommandMap not automatically being unmapped when the module is disposed - could that be the problem?

  6. 6 Posted by Christophe on 21 Feb, 2012 12:52 PM

    Christophe's Avatar

    Stray, I checked the dispose function used and there are those 2 lines :

            _moduleCommandMap = null;

    So I assume the moduleCommandMap is properly unmapped when the module is disposed.

  7. 7 Posted by Stray on 21 Feb, 2012 12:55 PM

    Stray's Avatar

    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?

  8. 8 Posted by Christophe on 21 Feb, 2012 01:09 PM

    Christophe's Avatar

    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 itself.

    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 assets.
    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

  9. 9 Posted by Stray on 21 Feb, 2012 01:58 PM

    Stray's Avatar

    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).

    It can be solved though! Don't lose hope :)


  10. 10 Posted by Christophe on 21 Feb, 2012 02:36 PM

    Christophe's Avatar

    Thanks Stray for the offer,

    But it's a company project so I am not allowed to send you a zip :-)

    I have a class in that minigame containing only constants though, do I have to manually do something on it to make sure it's destroyed ?

  11. 11 Posted by Christophe on 21 Feb, 2012 03:41 PM

    Christophe's Avatar

    I thought I was going to give you an update :-)

    I have waited like 10/15 sec after the first launch/close and it doesn't do it any more if I wait.
    So it could be just a matter of garbage collection happening late ?

  12. 12 Posted by Stray on 21 Feb, 2012 03:50 PM

    Stray's Avatar

    Hi Christophe - that sounds like exactly what it is.

    What's your app/player version?

    You can force/hint gc in newer versions, but if that's not viable then there are less elegant methods for forcing cleanup.


  13. 13 Posted by Christophe on 21 Feb, 2012 03:59 PM

    Christophe's Avatar

    I force the gc when it's a game, and it fixes the issue.

    People can only run our app if they have Flash 10, so I think it's ok to force the gc, isn't it ?


  14. 14 Posted by Stray on 21 Feb, 2012 04:13 PM

    Stray's Avatar

    That does sound fine - yes, I remember in FP9 it only worked for debug players, but I think in FP10+ it's in the release player as well.

    Make sure you test with the release player as well though - Adobe documentation on this is still a bit sketchy (as always).


  15. Ondina D.F. closed this discussion on 29 Feb, 2012 11:19 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac