I am not. Thanks for pointing it out, this is the likely cause of my problems. I dump out many XMLElement objects to strings but probably there are xdoc objects created that needs to be freed. Will fix.
Also submitted issue to LightXML.jl on github: https://github.com/JuliaLang/LightXML.jl/issues/16 Thanks, Robert Den torsdag 22 januari 2015 kl. 01:50:34 UTC+1 skrev Tony Kelman: > > Are you explicitly calling free(xdoc) > https://github.com/JuliaLang/LightXML.jl/blob/d6584b80d52e8e16f18dac45bdf326edf0eb6534/src/document.jl#L70 > anywhere? > I don't think LightXML is setting any finalizers currently. > > On Wednesday, January 21, 2015 at 3:43:57 PM UTC-8, Robert Feldt wrote: >> >> No, I'm pretty sure it doesn't: >> >> https://github.com/JuliaOpt/NLopt.jl/blob/master/REQUIRE >> >> I just realized one of the opt runs is actually calling out to the >> LightXML package. I think it is likely the mem leak is in there. We create >> a very large number of XML objects, dump them to strings and then don't >> hold on to them from the Julia side. I guess it might not be releasing them >> on the C side of LightXML or in the julia binding. Just a guess though. >> >> Cheers, >> >> Robert >> >> On Thu, Jan 22, 2015 at 12:08 AM, Jameson Nash <vtj...@gmail.com> wrote: >> >>> Does NLopt use the FastAnonymous package to create function closures? >>> >>> On Wed, Jan 21, 2015 at 4:58 PM Robert Feldt <robert...@gmail.com> >>> wrote: >>> >>>> I am running optimizations using different algorithms within the >>>> NLopt.jl package. Memory slowly builds until the julia process is killed. >>>> I >>>> thought the problem might be that the NLopt opt objects leaks some memory >>>> so I tried the following code after each optimization run (there is a big >>>> loop running multiple optimization runs after each other) to release the >>>> NLopt::Opt object saved in my nlopt in "slot" named "opt" object: >>>> >>>> # Overwrite the opt object to try to give back its memory. There >>>> seems to be mem leaks >>>> # when we have long-running opt runs: >>>> NLopt.destroy(nlopt.opt) # Not sure what is the effect of this but we >>>> try... >>>> nlopt.opt = nothing >>>> gc() >>>> >>>> but memory keeps building. I guess it could be in my (large and very >>>> complex and thus hard to distill down to an example) code used in the >>>> fitness function that NLopt calls out to but this is normal Julia code and >>>> should be garbage collected. I realize it is hard to debug without more >>>> concrete code but if anyone has ideas on why the Julia process might >>>> slowly >>>> but continuously be increasing its mem use (I'm running on a MacBoock Pro >>>> with Yosemite) I'd appreciate any tips/pointers or how to debug further. >>>> >>>> Each NLopt run is on the order of 15 minutes with around 2000 function >>>> evaluations. >>>> >>>> Regards, >>>> >>>> Robert Feldt >>>> >>>> >> >> >> -- >> Best regards, >> >> /Robert Feldt >> -- >> Tech. Dr. (PhD), Professor of Software Engineering >> Blekinge Institute of Technology, Software Engineering Research Lab, and >> Chalmers, Software Engineering Dept >> Explanea.com - Igniting your Software innovation >> robert.feldt (a) bth.se or robert.feldt (a) chalmers.se or >> robert.feldt (a) gmail.com >> Mobile phone: +46 (0) 733 580 580 >> http://www.robertfeldt.net <http://www.cse.chalmers.se/~feldt> >> >
