[EMAIL PROTECTED] schrieb:
>>> It got worse (using trunk rev 15905).
>>> After 3000 qx.ui.core.Widgets I stopped. Leaked already >50MB.
>
> As nothing seems to have further improved so far, I wrote a small class
> for finding the missing leaks. Actually it just scans the qx-namespace and
> prints all living object (and the first found reference-path to this
> object).
Nothing is quite dramatic. We have fixed all known missing destructor
sections now. At least that would mean that every component in qooxdoo
really destroys all child elements when disposed. This was not given
previously in the previous 0.8 versions.
> I will post this class the following days (needs some polishing, currently
> its just hacked together) but as a quick result here is the output which
> shows, that references on 'qx.html.Element' seem to cause the leak, though
> all widget and element instances under test are correctly disposed.
>
> ------
> ERROR: 1945ms LeakSearcher[hp]: Found disposed but still referenced Obj
> 'qx.html.Element' , hash '10', path:
> 'qx->Bootstrap->$$registry->qx.core.ObjectRegistry->__registry->2->__context->_modified->10'
> -----
> Translated it just means, that in the ObjectRegistry an Object with hash
> '2' holds references to disposed qx.html.Elements in its variable
> '__context._modified'.
> This message I get for quite a lot already disposed qx.html.Elements.
>
> Object with hash '2' is the following:
> ------
> INFO: 1948ms LeakSearcher[hp]: Found living Obj 'qx.util.DeferredCall' ,
> hash '2', path:
> 'qx->Bootstrap->$$registry->qx.core.ObjectRegistry->__registry->2->__context->__deferredCall'
> --------
>
> Though maybe not seeable in the first moment, one will find, that the
> '__context' of this 'DeferredCall'-instance points to the statics of
> 'qx.html.Element', and thus I conclude the static
> 'qx.html.Element._modified' - variable is holding references to disposed
> qx.html.Elements..
>
> I couldn't resist to dig deeper and found a really nasty bug on Element
> disposal, which happens, when Elements are disposed in the wrong order.
> Say we have 2 elements: ParentElem und SubElement. When ParentElement is
> disposed first, a reference to itself stays in the static _modified-map.
>
> The following stacktrace (read from bottom to top) tries to explain this.:
>
> - ParentElem._scheduleChildrenUpdate <-- puts reference of
> disposed ParentElem
> in _modified Map
> - ParentElem.__removeChildHelper
> - ParentElem.remove()
> - SubElem.destruct() <-- child tries to remove itself
> from parent, thus calls 'remove' on parent.
> - SubElem.dispose() <-- for each children dispose is called
> - ParentElem.disposeArray()
> - ParentElem.destruct() <- normal destructor call,
> calls diposeArray to release children
> - ParentElem.dispose() <- parentElem is disposed somewhen
>
> Actually it looks like that this should be avoided, at least
> __removeChildHelper checks, whether the qx.html.Element._element is set.
> Unfortunataly at this moment the destructor of ParentElement hasn't
> finished yet and _element is still set.
However the $$disposed flag applied by qx.core.Object is already true.
I've commited a fix in revision 16116. Thanks for the pointer.
>
> I have some ideas how to solve this, it's your turn to decide on the right
> one :D ...
> 1) reorder Element disposal to avoid this situation
> 2) make __removeChildHelper call isDisposed() before scheduling the
> children update and check other places where _element is checked for null.
> 3) rearrange order in the destructor: call _disposeArray("__children")
> after all other fields (at least _element) are reset. Beware: this might
> prevent correct removal of child-DOM-Nodes (as in 0.7.3). Since at least
> the DOM-Node of ParentElem is removed, this shouldn't be a problem here,
> because the ParentElem is removed and the browser should correctly garbage
> collect all still connected children-DOM-nodes.
> 4) On Element.flush() discard disposed references.
>
> As a quick test I chose idea 2+3 and now 20.000 created/destroyed
> Widgets/Labels 'only' leak about 8MB.
> As I can't find any wrong Javascript references anymore, I suppose this is
> either the leaking ObjectRegistry or I just disabled correct DOM-node
> removal again ...
>
> As I consider this whole situation as very fragile (even when fixed
> somehow its too easy to introduce the same bug again by chance), I'll put
> some final work in polishing and posting the small leak-finder.
> With that you'll be able to write unit-tests which hopefully automatically
> can test correct disposal of any Qooxdoo-object.
Ok, fine. Thanks for your work. Really appreciated.
Cheers,
Sebastian
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
