I think there are probably still bugs in beta2. I haven't used more recent builds to profile anything recently, but in general the profiler seems to be working well enough for me to track down problems. However, if you think you've found a bug, please file it. If you have time to try a more recent build before filing the bug, I'm sure the profiler engineers will be happier.
I don't recall the format of the chains OTOH, but there can still be chains that aren't showing a problem. Usually, if the path contains a weak reference, it is time to stop looking and try another chain since it is probably that some other chain is keeping the weak reference alive. Be sure you understand when to use loitering objects view and when it will show false positives. Otherwise you'll be looking at chains that are alive for a reason. I almost never use loitering objects view. Alex Harui Flex SDK Developer Adobe Systems Inc.<http://www.adobe.com/> Blog: http://blogs.adobe.com/aharui From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of brett.adam Sent: Tuesday, December 22, 2009 8:05 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Flash Builder 4 Profiler and memory leak hunting I've seen some older threads on this topic, but not a recent one given the recent release of FB4 b2 As Doug McCune noted some time back, the profiler in FB4 produces some confusing output in the Object References view on a (supposedly) un-GC'able object. In FB4b2 I'm still seeing many long, repetitive back reference chains that originate with supposed GCRoot instances. In the *vast* majority of cases, these reference chains are starting from GCRoot objects that are nothing more than the internal MXML generated binding instances - the "result" array and "target" references of the MXML binding machinery. I can't see at all how these objects are GCRoot objects given that they're completely local to the very instance object I'm seeking to have GC'd. I'm also seeing huge numbers of chains that are essentially circular or "parent/child" reference chains with the occasional binding between parent/child view properties thrown in. There's nothing in these chains that appears to be a genuine GCRoot. They're all just paths within the bolus of objects that comprise the view hierarchy that I so urgently want to see GC'd. Given that the 4.0 SDK now correctly uses weakRefs within the generated binding PropertyWatcher instances (yay!), I'd expect these to be completely ignored in this report, rather than turning up a *few hundred times* in the output. It also seems to me that showing a chain that has a weakRef in the middle of it is completely pointless and only adds more noise to obscure whatever the real problem is. Or am I missing something on that one? I'm also seeing chains that are nothing more than the object itself, as Doug previously reported. Does anyone on this list have a real understanding of the current state of the memory leak debugging tools in FB4 - i.e. are they simply not finished yet? Should I waste any more time with them at this point? And, as the obvious followup question, does anyone have suggestions of other tools or new techniques to hunt down and obliterate memory leaks in Flex apps?