Paul,
In step 3, when they click the X and ModuleLoader unloads the module, do you
see the module unload in the debugger player? I think you would see a line
like [UnloadSWF] in the debugger console.
In step 4, are the "children" you refer to the child UI widgets of the module?
One technique you could try is to add code that starts removing the children
from their parents after the module is loaded. Then you might find that
removing one particular child causes the problem. Make sure Timers and event
listeners have been managed properly.
HTH,
-Alex
On 1/30/19, 11:18 AM, "Paul Stearns" <pa...@compuace.com.INVALID> wrote:
I started down this path some time ago, when I ran into a dead end and
other projects piled up, I needed to abandon the hunt for memory leaks in my
application. I am now 100% focused on solving this as it has gotten to be a
real problem.
I use FlexBuilder 3 as a tool. I am not opposed to using other tools. Where
I am right now;
1) I made a copy of my application and am working with one module
(moduleLoader) and the main application.
2) The application is basically a shell with a menu bar, when a user
selects a menu item it finds an existing moduleloader, and loads the .swf file
using the moduleloader.
3) When the user clicks the "X" on the panel within the moduleloader it
unloads the module.
4) After the module unloads all of its children seem to stay in memory, and
never go away.
At the moment The profiler has stopped functioning with the folloowing
error;
java.io.IOException: Unknown 'agent -> profiler' command: 60 at
com.adobe.flash.profiler.internal.ProtocolHandler.process(ProtocolHandler.java:134)
at
com.adobe.flash.profiler.internal.PlayerSession.run(PlayerSession.java:383)
at java.lang.Thread.run(Unknown Source)
I need help fixing that and/or finding another memory profiler. I would
like to have the profiler use a relatively current version of the Flash VM.
My current strategy is to strip things out until the problem goes away.
