I think the problem is that xmlFree and xmlMalloc are not functions, but pointers to functions (there are macros in the header files to make this transparent when called from C/C++).

This works for me:

      attach_variable :__xmlFree, :xmlFree, callback([ :pointer ], :void)

      attach_variable :__xmlMalloc, :xmlMalloc, callback([ :size_t ], :pointer)

      def self.xmlMalloc(size)

        __xmlMalloc.call(size)

      end

      def self.xmlFree(ptr)

        __xmlFree.call(ptr)

      end

That attaches xmlMalloc and xmlFree as global variables exported by the library, then provides wrappers to call them from ruby.

On Wednesday, 6 February 2013 09:59:11 UTC+10, Paul Hinze wrote:

Thanks for getting back to me, Wayne.

On Tuesday, February 5, 2013 3:22:49 PM UTC-7, Wayne Meissner wrote:

You're correct that MemoryPointer#free won't do anything for you - it only frees the memory allocated for itself.

From looking at other C based examples, it should be as simple as adding the following (after reading result from the strptr):

  C::LibXML.xmlFree(strptr) unless strptr.null?

Okay this is the direction I was headed in, but whenever I call either xmlFree or xmlMalloc, ruby (latest 1.9.3, but also tried ree for fun) crashes and burns like so:

https://gist.github.com/phinze/f2f89ce8864b66d3e0f9

Here's where I bind the functions - It's pretty straightforward:

https://github.com/phinze/xml_security/blob/39d4cb62776b28d6fce1b8d8fd277a4d2339158c/lib/xml_security/c/lib_xml.rb#L20-L21

And here's a really simple test case that blows up on the xmlMalloc call:

https://github.com/phinze/xml_security/blob/bdbe54d0f2c1c05bcace7cf29e3f1b0c1b274368/spec/xml_security/c/lib_xml_spec.rb

Now, libxml2 does some funky stuff with its memory management functions [1], which means that the function declarations in the code have several layers of indirection built in. I'm wondering if it's possible that this is confusing to the FFI layer.

If you'd like, I can extract this into a more isolated test case for you, but I wanted first to get a feel for whether or not this could possibly be an FFI issue.

I'm thinking a decent workaround is to just reach over to libc's malloc/free, which I'll be working on in parallel to this investigation. Still, it'd be nice to get to the bottom of this.

Thanks for your time,

Paul

[1] http://www.xmlsoft.org/xmlmem.html

--
 
---
You received this message because you are subscribed to the Google Groups "ruby-ffi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-ffi+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.