On Tue, May 7, 2013 at 10:30 AM, Aaron Cruz <aa...@aaroncruz.com> wrote: >> I do not know what you are talking about (properties are being set) >> and what you mean by ".new". If you refer to the properties that are >> set in the various C init functions, then it does not matter. > That is what I meant. > >> I was using swig v2.0.4. > And I v2.0.7 > > If you get interested in scratching your itch, I look forward to what you > come up with. Otherwise I will continue to try to debug this as problems > arise and I will keep you updated if I find the bug.
As a point of comparison, I made a test in python, and it is calling the destructors correctly. Looks like ruby needs something else in the swig definition. Might be interesting to try an older version of swig < 2.0; I will try to do that soon. > -- > aaron > > On May 7, 2013, at 7:24 PM, Dan Dennedy wrote: > >> On Tue, May 7, 2013 at 9:58 AM, Aaron Cruz <aa...@aaroncruz.com> wrote: >>> Thanks for looking into this. I will run some more tests. >>> >>> What do you mean by "when the playlist is deleted"? Because setting it to >>> nil was not affecting anything on my side. >> >> I mean when you work in C++ and delete the playlist or when you work >> in C and call mlt_playlist_close(). >> >>> You say that Mlt::Producer.new is the preferred form. Is that also true with >>> Mlt::Factory.consumer? Why? >> >> yes, the C++ constructors for Producer, Consumer, Transition, and >> Filter use mlt_factory. The reason it is preferred is simply because >> it is the cleanest and most obvious thing to use in the high level >> languages. Playlist does not go through a factory because it is not >> extensible at the C level - same goes for Multitrack and Tractor. >> >>> I see in your source that a lot of properties >>> are being set on .new and it looks like the defaults on Factory.x are maybe >>> different (I can't find exactly where they are). >> >> I do not know what you are talking about (properties are being set) >> and what you mean by ".new". If you refer to the properties that are >> set in the various C init functions, then it does not matter. >> Technically there is no difference between using Mlt::Factory.producer >> and Mlt::Producer.new because the Factory methods simply invoke the >> appropriate constructor! The fact that I am seeing different behavior >> in ruby when making that change says something about the swig >> definition - at least for ruby - even though it has declared the >> Factory methods as %newobject. However, the biggest surprise is the >> failure to destroy a playlist (after nil and GC) even though >> Mlt::Playlist.new is a plain old constructor and not needing a >> %newobject! That is a total head scratcher. I was using swig v2.0.4. >> >>> BTW, if you want to play with this stuff in Ruby and get some great info, >>> there is an irb replacement called pry. It has great stuff like calling 'ls' >>> on classes or objects to get all the class/instance methods/variables up the >>> call list. It is how I discovered most of the mlt library before I could >>> read C. You can even cd into classes or instances to look around. You can >>> also view the ruby and C source code for classes/methods >>> https://github.com/pry/pry/wiki/Source-browsing >>> Here is a little sample >>> https://gist.github.com/pferdefleisch/635ea97b169546a04dd0 >>> Sorry for the aside :) >>> >>> >>> On May 7, 2013, at 6:35 PM, Dan Dennedy wrote: >>> >>> 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-+ >>> >>> >> >> >> >> -- >> +-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
