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.