Yeah, ok some clarification (rather than bashing the email out then going home for the night ;) )
I'm debugging and watching the numChildren properties and the selectedChild properties. (The object extends viewstack btw). I can see the view in the viewstack, then after running though the code that removes the child from the viewstack, I can see the numChildren has dropped from 1 to 0, and the selectedChild (and selectedIndex) both are consistent with having no child in the viewstack. In terms of profiling... I am starting up the app, getting the view created, and running the code once to clean up. Then I take a memory snapshot. I do the same action another two times (to get to the prime). Then I take another snapshot. Then I work out the loitering objects. The line with the instance being the viewstack object and the property being [child0] is what makes me think it still has a reference to the view and the reason (or one of them ;) )why it isn't being garbage collected... And Alex, I think I've read everything on your blog at least 8 times ;) Gk. Gregor Kiddie Senior Developer INPS Tel: 01382 564343 Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ Registered Number: 1788577 Registered in the UK Visit our Internet Web site at www.inps.co.uk <blocked::http://www.inps.co.uk/> The information in this internet email is confidential and is intended solely for the addressee. Access, copying or re-use of information in it by anyone else is not authorised. Any views or opinions presented are solely those of the author and do not necessarily represent those of INPS or any of its affiliates. If you are not the intended recipient please contact [email protected] ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Alex Harui Sent: 05 May 2009 17:57 To: [email protected] Subject: RE: [flexcoders] Profiler telling lies? First, make sure you are using the right view. If you are looking at loitering objects but your scenario should not be using that view, you will get false positives. I've explained why on my blog. If you're looking at a memory snapshot, I would dig further as I haven't seen the profiler 'lie' in this situation yet. Remember that Flex containers are IRawChildrenContainers. There is no "children" array, and numChildren does not count borders and other chrome. Alex Harui Flex SDK Developer Adobe Systems Inc. <http://www.adobe.com/> Blog: http://blogs.adobe.com/aharui <http://blogs.adobe.com/aharui> From: [email protected] [mailto:[email protected]] On Behalf Of Mark Doberenz Sent: Tuesday, May 05, 2009 8:04 AM To: [email protected] Cc: <[email protected]> Subject: Re: [flexcoders] Profiler telling lies? Check your event listeners because if you're not using weak references then the garbage collector won't remove it. Disregard if you already knew that one :) On May 5, 2009, at 7:58 AM, "Gregor Kiddie" <[email protected] <mailto:[email protected]> > wrote: Hi all, I'm trying to work out where a memory leak is occurring in our application (putting me into Jeff's hell from last week). When profiling the app, it claims there is still a back reference to its parent on the display list (even though I remove it!) at [child0]. When I debug the application, the child is removed as I'd expected, and the children array is empty. So which one is lying? The profiler when it tells me there is still a back reference to the parent as [child0] or the debugger when it tells me the child has been removed... Gk. Gregor Kiddie Senior Developer INPS Tel: 01382 564343 Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ Registered Number: 1788577 Registered in the UK Visit our Internet Web site at www.inps.co.uk <blocked::http://www.inps.co.uk/> The information in this internet email is confidential and is intended solely for the addressee. Access, copying or re-use of information in it by anyone else is not authorised. Any views or opinions presented are solely those of the author and do not necessarily represent those of INPS or any of its affiliates. If you are not the intended recipient please contact [email protected] mlmsg #ygrp-msg p a span.yshortcuts { font-family: Verdana; font-size: 10px; font-weight: normal; } #ygrp-msg p a { font-family: Verdana; font-size: 10px; } #ygrp-mlmsg a { color: #1E66AE; } div.attach-table div div a { text-decoration: none; } div.attach-table { width: 400px; } -->
