Memory leak in the randomisation analyses about biodiverse HOT 27 CLOSED

There is no memory leak (at least not as identified using Devel::Cycle).  It is 
more
to do with the way Perl manages memory and can be reduced by more judicious use 
of
data structures.  This process is ongoing.  

Actually, there is a memory leak but it is not due to a reference cycle in the
objects.  It seems to occur after a data set is loaded from a bds file and a
randomisation is added, so something is keeping a reference outside the 
object's scope.

More hunting is needed.

Need to try Test::Weaken.
http://search.cpan.org/~jkegl/Test-Weaken-3.004000/lib/Test/Weaken.pm

A workaround has been implemented for use until (and even after) we solve this 
issue.
See http://code.google.com/p/biodiverse/wiki/LoadAndRandomise

This issue was updated by revision r949.

More leak hunting, but have found nothing.

This issue was updated by revision r1112.

Switching to Class::Inspector from Devel::Symdump.  
Might make some difference, but need to benchmark.  
Next is to test cloning as the source.  

This issue was updated by revision r1113.

Add script to run leaktraces.

This issue was updated by revision r1148.

Some musings.

Looks like this issue does not manifest under Strawberry Perl 5.16 (either of 
x32 and x64).  

Either perl has fixed itself, or something in the dependency chain was the 
cause and has been fixed (or both).

Leaving open for now, as we also need to test on Linux.  

Possibly it was fixed by this:  
http://repo.or.cz/w/Text-CSV_XS.git/commit/0cee5f2cbe2e83a

No, it is still there.  
Strawberry 5.16.3 x64.

This issue was updated by revision r1653.

Add config parameter to control the progress dialogue.  
After turning it off it looks like the leakage is coming from either 
Biodiverse::GUI::ProgressDialog or from Gtk.  This is because there is no 
increased use of memory with no progress dialogs being shown.  

Looks like Gtk are on it.  

https://bugzilla.gnome.org/show_bug.cgi?id=685959 (marked as fixed) and 
https://bugzilla.gnome.org/show_bug.cgi?id=671538

This issue was updated by revision r1659.

Make sure the config parameter is boolean.  

This issue was updated by revision r1662.

Store the text and progress widgets directly.  
It doesn't fix the issue, but should at least speed things up a touch since we 
don't repeatedly call dlgxml->get_widget.

This issue was updated by revision r1663.

Add test script to hunt leaks.  
Memory usage increases as the number of progress dialogs increases.
It is stable if only one progress dialog is used, no matter for how long.  
The next approach is to not use the Glade file progress dialog, and generate 
new ones directly.  There is much leakage under the current approach.  

It seems a reasonable workaround would be to reuse the same dialog and
show/hide it. (Cache the Gtk2::GladeXML instance in a global in new and hide 
the dialog
instead of destroying it in destroy).
Under Linux the dialog seems to grow vertically slightly each time, but
looks fine on Windows.
In both cases the memory use is steady.

The issue with hiding is that we often need more than one progress dialog at a 
time.  Updating a single dialog will hide the higher level progress.  

Keeping a single dialog overall is a good idea, though, and is already logged 
as issue #295 .  In this approach we have a single window and add/remove 
sub-widgets as needed.  The dialog can be hidden when there are no more widgets 
to update.  

WRT recreating each time for now, the widget is not that complex to create - it 
is just a vbox in which one packs text and progress bar widgets.  

This issue was updated by revision r1666.

Ahab almost has his whale. 
Replace the GladeXML progress dialog with one rolled by hand.  
Memory usage no longer increases anywhere near the same rate as before.
A remaining issue is that closing the dialog does not cancel the operation.  
This needs to be looked into.  

This issue was updated by revision r1667.

Add signal handler so we destroy the progress widgets when the window is 
closed.  This then triggers the analysis cancellation.

This issue was updated by revision r1669.

Merge changes into the trunk. 

This issue was updated by revision r1670.

Remove some debugging code that causes croakage.

This issue was updated by revision r1671.

Merge latest change into trunk.  

Add milestone for 0.18

At long last this issue can be marked as fixed.

This issue was updated by revision r1688.

Add a test file (even though the issue is closed).  

This issue was updated by revision r1769.

Delete branch associated with this issue.