opencamlib KD-Tree leaks memory like a sieve

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run a dropcutter (Zigzag via HeeksCNC) operation on an STL object
2. Watch memory blow out.
3.

What is the expected output? What do you see instead?

Expected output is for memory load to stay more or less constant after the 
initial KD-tree for the STL object has been built. instead, memory (huge 
amounts in the case of complex operations) is leaked.

What version of the product are you using? On what operating system?

trunk svn r564, Ubuntu 10.04

Please provide any additional information below.

I have attempted to fix these issues - as I am unfamiliar with the code my 
fixes might not be exactly what you intend style-wise, however they work for 
me, and make it possible to process STL files that would quickly exhaust all my 
memory and swap in HeeksCNC.

Patch attached, though i expect it will need some cleanup to remove comments 
and unecessary stuff. 

Original issue reported on code.google.com by ikekr...@gmail.com on 13 Nov 2010 at 1:08

Attachments:

• memoryleaks.patch

[GoogleCodeExporter]

good work, thanks.
I have applied your patch essentially as is in r565

I think I am seeing a slight performance decrease, not sure why.

Looping through the triangle list in the constructor of kdnode3.h isn't exactly 
elegant, would prefer just an assignment.

I think there's an issue with wrapping the destructors correctly in python 
also, will have to check this.

Original comment by anders.e...@gmail.com on 13 Nov 2010 at 10:54

• Changed state: Accepted

[GoogleCodeExporter]

I will work on it some more - C++ isn't really my thing, and this was really 
just a 'hack it till it works' attempt. It should be possible to use lists of 
pointers consistently instead of concrete objects to minimise memory use and 
eliminate a lot of copying. 

Previously in heekscad, the operation would run out of memory, be silently 
killed by the OS, and you would just get some partial path generated and 
displayed, in many cases it wasn't obvious the g-code was truncated.

Valgrind does continue to show some memory leaked in the python binding stuff, 
but this might be normal, I really haven't done much with C++/boost/python etc.

Glad to know its been rolled into the code, cheers.

Original comment by ikekr...@gmail.com on 13 Nov 2010 at 8:15

[GoogleCodeExporter]

New build for HeeksCNC for windows has this new ocl version in it and zigzag 
now runns nicely on windows too. (Ver 0.17.1 tested) However, waterline still 
leaks badly. Could someone check if there are similar fixes to be done in 
waterline as there was in zigzag?

Original comment by tha_krea...@hotmail.com on 14 Feb 2011 at 7:57

[GoogleCodeExporter]

closing this issue.

Original comment by anders.e...@gmail.com on 19 Apr 2012 at 5:31

• Changed state: Fixed