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.: 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
