

![]() | 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: |
4 messages in net.java.dev.jna.usersRe: [jna-users] SIGSEGV on Memory.fre...| From | Sent On | Attachments |
|---|---|---|
| Robin Vobruba | Mar 14, 2009 1:38 am | |
| Timothy Wall | Mar 14, 2009 5:23 am | |
| Robin Vobruba | Apr 1, 2009 12:22 pm | |
| Robin Vobruba | Apr 1, 2009 12:26 pm |

![]() | 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] SIGSEGV on Memory.free() on a callback struct | Actions... |
|---|---|---|
| From: | Robin Vobruba (cze...@sunrise.ch) | |
| Date: | Apr 1, 2009 12:22:41 pm | |
| List: | net.java.dev.jna.users | |
2009/3/14 Timothy Wall <twal...@dev.java.net>:
On Mar 14, 2009, at 4:39 AM, Robin Vobruba wrote:
Hello! first of all, thank you for JNA! i was trying to use SWIG before, and it was giving me so many problems. working with JNA is much more comfortable.
we have a native application from which we invoke the JVM. we use JNI for C->Java and JNA for Java->C communication. The main part of the Java->C communication works through a native struct, which is filled with function pointers. The Java/JNA wrapper class is both instantiated and then passed to a Java function with JNI. This worked well when we linked the application (its actually a plugin shared library used by the application) to the jvm with -ljvm. We found out, that this is not flexible enough for our needs, and we have to load the JVM dynamically now (eg. LoadLibrary() on windows, dlopen() on unix). since we do this, we always get a SIGSEGV when trying to create the callback with JNI. To make it short, i will describe what we do with JNI in mixed C/Java code, as this shortens the code a lot. [code] // C part ... const struct ClbStruct* myNativeClb = ...; Pointer clbStructP = new IntByReference((void*)myNativeClb).getPointer().getPointer(0); MyJNAClbWrapper clbWrp = MyJNAClbWrapper.getInstance(clbStructP);
You've omitted the part where you hand Java the pointer value for your structure. That's the part that's likely functioning differently.
the four lines above are where i hand java the pointer value to my structure. In my code, it is C; i just wrote it in Java here for simplicity. i am pretty sure the pointer is ok, as it works if hte JVM is not loaded dynamically. these same four lines in C are a lot of code, and spread through various functions. should i copy it together? i check for exceptions and ==NULL after each JNI function call, and it worked well so far, so i guess these things are ok.
// in Java ... class MyJNAClbWrapper extends Structure implements Structure.ByReference {
public static MyJNAClbWrapper getInstance(Pointer memory) {
MyJNAClbWrapper _inst = new MyJNAClbWrapper(); _inst.useMemory(memory); _inst.read(); return _inst; } ... } [/code] through debugging the java part, i found out that the SIGSEGV happens in the line with _inst.read();
Which means the pointer value passed to the structure is likely a bogus one.
and from the JNI log, i see thta the last method cammed is Memory.free(). I guess the problem lies there, as i can not see why any native memory should be freed here. the only thing involved is a const struct pointer, that contains only function pointers, and i only want JNA to read these addresses. Is there some way to tell JNA it shall not free anything? Or is my problem a different one?
The structure frees already-allocated memory because you told it to use a new pointer as its native backing. Nothing interesting there.
A new Pointer? how would i pass it an old Pointer? I mean... I alloc a struct in C, pass a pointer to it to Java, and later i want ot free the struct in C again. how would i do that JNA does not free it already, and why does it free it during read()? does it only do that cause something went wrong during the read() ?
I cant see why the dynamic loading of the JVM should cause such a difference. The only idea i have is that we are doing something wrong, and the dynamic loading (different use of memory maybe), converts the problem from a memory leack to a crash.
If this is not enough information, i can supply more; just tried to keep it as short as possible.
System Details: Ubuntu Linux 8.10 32bit SUN JDK 1.6.0_10 gcc 4.3.2 Intel Duo







