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?
