Hi,
I filed bug http://bugzilla.qooxdoo.org/show_bug.cgi?id=6473
Best regards,
Jeroen
From: Martin Wittemann [mailto:[email protected]]
Sent: Friday, June 01, 2012 8:21 AM
To: qooxdoo Development
Subject: Re: [qooxdoo-devel] Memory leak detection
Hey,
Thanks for the pointers. I found "qx.util.DisposeUtil.disposeTriggeredBy" in
the framework which solves my problem of leaking tooltips, fonts etcetera.
Using the disposerDebug version I found many other things so my code is much
better now!
Sounds like a success, congratulation. :)
While looking at objects not being disposed (using debuglevel 3 the objects are
logged to the debug window) I also found a few leaks in the V1.4.1 Qooxdoo core
code which might interest you.
Very good!
They all involve the TreeVirtual control:
Column model:
Because I configured nothing specific qx.ui.table.columnmodel.Resize is used as
the column model. By default no behaviour is set, so in the init() method the
following is executed:
this.setBehavior(new qx.ui.table.columnmodel.resizebehavior.Default());
This behaviour is however never freed. I introduced a member "__privBehaviour"
to store the result of "qx.ui.table.columnmodel.resizebehavior.Default()" to
dispose it in the destructor.
Well, as the framework is the one creating it, there should not be any need
that you take care of that yourself. So thats something we should fix in the
frameworks code base.
TreeVirtual.js
In the constructor several objects are created when no "custom" data is
provided (which I don't). They are used a little further along the way. The
following thing are leaked using this mechanism:
- The table model, which I fixed by introducing a destructor and calling
this.getTableModel().dispose();
- The data row renderer which I fixed by storing the current model
before call "this.setDataRowRenderer" and disposing the stored current model
after the call
- The data cell renderers which I fixed by iterating the currently set
renderers (tcm.getDataCellRenderer(i)) and disposing them before the loop with
statement "tcm.setDataCellRenderer(i, i == treeCol ? stdcr : ddcr);"
- The defaultDataCellRenderer because I only have one column which
becomes the "treeCol" so only the treeDataCellRenderer is used. I added a
detection for this and when defaultDataCellRenderer or treeDataCellRenderer is
not set to any of the columns I dispose this object as well.
Can you please indicate if these are indeed issues in the core code or if I am
not using the framework correctly?
All your fixes sound like workarounds you should never have been needed. Would
you be so kind and open up a bug report describing these memory issues? We
should check on all of these and fix them so you can get rid of your
workarounds and every other having the same issue of their memory leaks. ;)
Thanks,
Martin
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
