On Tue, May 7, 2013 at 4:02 AM, Aaron Cruz <aa...@aaroncruz.com> wrote: > No, it isn't open source (ATM). I would like to release part of it at some > point. > > The project is basically a simple RESTful web server wrapping the ruby swig > bindings that takes in API calls and consumes and produces JSON. It is > pretty much a ruby http version of melted that speaks JSON. If necessary I > could write up a dumbed down version for you to test. > > But I can't even get the garbage collection to work correctly with the > sample script I showed you. Once I got that to work I could use that > solution to see what I can do to fix my memory issues in my project. > > If you haven't run the script, I highly recommend it. > I am running mlt 0.8.2 and ruby 1.9.3p327 on OSX 10.7.5 > I have also tested mlt 0.8.2 with ruby 1.8.7p358 on ubuntu precise64 with > the same results. With this version, it seems to be releasing about 2MB RAM > after the nils and GC.
I did a little testing last night with your script. I put printfs in the Producer and Playlist destructors, and I noticed that they were not being called. When I changed Mlt::Factory.producer to Mlt::Producer.new (the preferred form), I saw the producer destructors being called. (By that time I was not using the exact same script as you, so you may not necessarily see the exact same results.) Nonetheless, for some strange reason, I never saw the Playlist destructor called, and the playlist holds a reference to every producer added to it, which it eventually releases when either the producer is removed, when autoclose=1 and the producer has played out, or when the playlist is deleted. > Both of these i have tried w/ and w/o %trackobjects; I believe it is a swig definition problem, but I do not think %trackobjects will solve it. In fact, it might make the problem worse as it seems like it is more suited towards C++ classes that do not use reference counting. I am not sure how much more effort I will put into it. The effort I put forth now is based purely on curiosity, but I do have other pressing concerns. > -- > aaron > > On May 6, 2013, at 6:46 PM, Dan Dennedy wrote: > > This has worked in the past. I need to know more about your > application before I offer to debug these things for you. Is it an > open source project? > > On Mon, May 6, 2013 at 8:46 AM, Aaron Cruz <aa...@aaroncruz.com> wrote: > > Hi Dan, > > What you suggested (setting to nil) has never worked for me in the past. > > > I just created a little test to showcase this here > > https://gist.github.com/pferdefleisch/1e448e3257837ebeb2b3 > > My memory is never released. It stayed in my test with 100 short .movs right > > around 200MB with 0.0% CPU. > > I also tried something that I found on the SWIG page with the mlt.i file > > (you can see in the gist). > > > Since there seems to be no garbage collected playlist factory, I tried the > > same test above but with just connecting the consumer to a non-playlist > > producer with the same results, no memory released. > > > I have also seen strange things happen like when I set 'autoclose' to 1, as > > mlt plays my list, clips are removed, but memory is only released, and only > > a tiny bit, when I append new videos. Maybe this is a separate bug. > > -- > > thanks for your time, > > aaron > > > On May 5, 2013, at 8:24 PM, Dan Dennedy wrote: > > > On Sun, May 5, 2013 at 4:14 AM, Aaron Cruz <aa...@aaroncruz.com> wrote: > > > I am trying to create a reset functionality in my Ruby code that will clean > > up my consumer and playlist (Mlt::Factory.consumer and Mlt::Playlist > > respectively). > > > It seems like both the mlt_playlist_close and mlt_consumer_close functions > > were made for this but they are not included in the SWIG bindings. > > > Is there a reason they were left out? > > > Is there a better way to to this with the already provided interface? > > > > I would like my server to handle the reset instead of having to reset my > > server. I am also still having memory leak issues and I would like to tweak > > some things like this for some experiments. > > > -- > > > Thank you, > > > Aaron > > > > > The C++ destructors call the C close functions. When you release > > references in a scripting language and garbage collection occurs, then > > the C++ destructors are called. If you want to make cleanup more > > immediate in the scripting language runtime, then set the vars holding > > reference to nil and force processing the garbage collection. If you > > call the C close functions directly, then the C++ destructors will > > (eventually) call close on invalid pointers. > > > -- > > +-DRD-+ > > > > > > > -- > +-DRD-+ > > -- +-DRD-+ ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
