Replies: 2 comments
-
Sorry I did not see this issue until now! The answer to this really depends on that API. Some will use a shared buffer so there's no leak and no issue as long as different threads don't attempt to use the char* at the same time. It sounds like your case actually mallocs a buffer, in which case you would need to clean it up yourself. I would strongly recommend that you wrap logic using this buffer with a finally that explicitly frees it. Barring that, you should be able to wrap it with one of the jnr-ffi memory structures and set that to auto-release some time after it is GCable. Long story short, you probably are leaking if some C function allocates memory and you do nothing to ensure it gets freed. |
Beta Was this translation helpful? Give feedback.
-
Oh as for a place to discuss this... this is fine. Perhaps we should have a Matrix or Gitter or something for simple questions? |
Beta Was this translation helpful? Give feedback.
-
Sorry if this is sounds more like a question than an actual issue. I found no better place to ask this (if there's such a place, please let me know!)
I have a native function that allocates a string to the heap and returns a pointer to it. When I call this function using jnr-ffi, everything works as expected and I get a java string at the other side. However, I'm unsure whether I'm leaking memory by doing this. I'm assuming jnr-ffi is copying the string memory at some point, but is it free-ing the memory that was allocated by the native code?
If not, is there a way I can have my native library safely return a string without leaking memory?
Beta Was this translation helpful? Give feedback.
All reactions