On Thu, Sep 13, 2012 at 5:05 PM, Rafael Schloming <[email protected]> wrote: > On Thu, Sep 13, 2012 at 4:46 PM, Rajith Attapattu <[email protected]>wrote: > >> On Mon, Sep 10, 2012 at 1:36 PM, Rafael Schloming <[email protected]> >> wrote: >> > On Mon, Sep 10, 2012 at 9:26 AM, Darryl L. Pierce <[email protected] >> >wrote: >> > methods on Messenger and Message objects and by tying pn_messenger_free >> and >> > pn_message_free into the respective destructors, we could make things a >> > whole lot safer, e.g. avoid dangling pointers and the like that a user >> > could use to segfault the interpreter. >> >> Darryl, you could use %typemap(freearg) to ensure the respective free >> function is called to cleanup. >> How it gets called is also automatically handled by swig based on the >> host language. >> > > Maybe I'm missing something, but I don't think %typemap(freearg) helps in > this case. From what I understand it's used to clean up temporary memory > allocated for the purpose of argument processing. The situation I'm talking > about is when you allocate an object in C and return it to the interpreter, > e.g.:
Sorry I misunderstood. I thought it was for methods. It appears Ruby does have support for %newobject http://www.swig.org/Doc1.3/Ruby.html#Ruby_nn59 But it maybe simpler to use the strategy Rafi has used for the python binding. > msg = pn_message() > > What swig returns to the interpreter here is a wrapper around a pointer. If > that variable goes out of scope and the interpreter garbage collects it, > then only the wrapper is freed, and the memory pointed to by the internal > pointer is leaked. > > You can fix this by doing pn_message_free(msg) before it goes out of scope, > however for a short time you end up with the wrapping object having an > internal pointer that is invalid since it now points to freed memory. If > you the try to do things you can cause the interpreter to seg fault just > like the C runtime would seg fault if you were to try to use a pointer > after freeing it. > > You can use %newobject and %delobject to address this, however I'm given to > understand that support for that varies across target languages. It's > fairly easy to work around with a destructor in the wrapper layer as I've > done in the idiomatic python API layer. > > --Rafael
