I'll second that. I've found the profiler hard to rely upon. Running
my app in a browser alongside WSMonitor seems more convincing to me,
but that might be because it gives me the answer I expect & want (ie,
no leaks).
Guy
On 26/11/2008, at 3:08 PM, Alex Harui wrote:
SDK-18076 hasn’t got enough votes to go to engineering for
investigation. Most of the time, we find a bug in the user app.
Every once in a while we find something we missed, but it isn’t
SWFLoader, it is some control somewhere that doesn’t clean up.
AFAIK, several folks are happily deployed using SWFLoader or
ModuleLoader.
Most recently, we learned that some SWFs don’t fully unload their
debug info, invalidating the profilers results. I always advise
using the profiler to eliminate the odds of there actually being a
leak, but then, export your swfs for release builds and use a
release player and see what happens.
-Alex
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED]
On Behalf Of Jules Suggate
Sent: Tuesday, November 25, 2008 1:02 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Memory leaks in Flex SDK
Hi all,
I know this is a "multennial" subject, but I just checked Adobe's JIRA
and found three confirmed memory leaks in the Flex SDK :(
They are:
+ Memory leak in SWFLoader: https://bugs.adobe.com/jira/browse/SDK-18076
+ BindingUtils don't use weak event listeners, creating potential
memory leaks: https://bugs.adobe.com/jira/browse/SDK-14891
+ Flash Components break GC in FLex (while loaded at runtime):
https://bugs.adobe.com/jira/browse/SDK-13612
AFAIK, a well modularised application has to make use of SWFLoader for
dynamic linking, so that's a big worry as my app is designed to run
continuously in the background.
The second two are slated to be fixed in Flex Gumbo (not really
imminent but somewhat reassuring), however Adobe are particularly
quiet about the SWFLoader problem.
Anyone know of any workaround for these issues (esp. SWFLoader)?
Cheers,
Jules
