

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
3 messages in net.java.dev.jna.usersRe: [jna-users] Freeing returned memory| From | Sent On | Attachments |
|---|---|---|
| Neil C Smith | Jun 25, 2009 5:34 am | |
| Timothy Wall | Jun 25, 2009 6:19 am | |
| Neil C Smith | Jun 25, 2009 7:07 am |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [jna-users] Freeing returned memory | Actions... |
|---|---|---|
| From: | Timothy Wall (twal...@dev.java.net) | |
| Date: | Jun 25, 2009 6:19:40 am | |
| List: | net.java.dev.jna.users | |
On Jun 25, 2009, at 8:35 AM, Neil C Smith wrote:
Hi,
I'm using JNA to work on a binding to the Jack Audio Connection Kit at the moment as I need access to the API for a current project, and while there is an existing project using custom JNI (JJack) it doesn't offer the level of access to the underlying API that I'm looking for. There is a little extra overhead from using JNA, but it's definitely workable (low latency in a realtime thread), and that's without trying direct mapping yet!
Anyway, I've got a question concerning a number of methods that return an array of strings ( as const char ** ). According to the Jack API, I need to free the returned memory, so I'm returning them as a Pointer in the JNA interface and creating a String[], but then what's the best way to free this memory? I tried the method of wrapping the free() method in the CLibrary as has been suggested previously, but this crashes the VM. However, if I create the free() method in the JackLibrary interface, it all works fine. I don't know enough about C to know if this is normal to access a function through a library that's been compiled against. Is this way of doing it liable to break?
It's probably safer to go through the library you're dynamically loading, since it's possible that the "default" glibc on your system (the one you'd get with loadLibrary("c")) may not be the one that the JackLibrary was linked against. It's also possible (though unlikely) that JackLibrary is providing its own "free" implementation.
You might try running ldd against the JackLibrary to see what version of glibc it's linked against, and "nm" to see if there's a defined "free" function in it.
btw - JNAJack is going up at http://code.google.com/p/java-audio-utils/ - the download is just a 'proof of concept', but the code I'm working on is in the SVN repo.
Thanks and best wishes,
Neil
-- Neil C Smith Sound & InterMedia Artist / Arts & Technology Adviser http://neilcsmith.net







