JNI problem

Engines, Libraries and Tools JInput
#1

Hi

I’ve spent all day trying to find the bug in the linux ff code. The symptom is that each time the code is started, an event is uploaded to the device. The problem is, that the device I have can hold 8 events, and each time I run it, it doesn’t clear the old ones out.

I’ve written some test java code, that uses the same interface as jinput does, but this code doesn’t have the same issue. I have noticed a couple of things during the development of the new native interface and test code.

not doing a ‘free’ in the native code of the device node I’m using, seems to always cause the issue. adding this free seemed to fix the tests.

So i’m thinking that there are some references to objects or structs or something that the java code keeps alive some how. If I don’t specifically call the free by calling a dispose methed from the java side, then it always appens.

I’ve created a branch in CVS for the linux plugin dir and below, called forcefeedback, that contains the current work.

I’m most confused and admit that JNI is not my strong point.

Endolf

#2

Well, im n ot sure Im following BUT

If you are counting on finalizers, then don’t because you can’t. There is no gaurantee when if ever a given finalizer will get run.

#3

Hi

Nope, ran in to that one early on in my career :).

I’m using a shutdown hook on each rumbler to go through and clean it up, I can see them being called. They call the same code as my test class, which is puzzling, I can only assume that the plugin has hold of some other resource that the tests don’t use.

Endolf

#4

Hi

Ok, further information.

I’ve added a shutdown hook to the LinuxEnvironmentPlugin that calls a public static method on itself that runs through the native interface closing all the controllers.

This runs happily, but doesn’t solve the problem.

When I call the method myself, from my test class on shutdown, it works fine. There appears to be some difference in the way that calling this shutdown happens depending on wether it’s a shutdown hook or the main method. The only thing I can think of is that it’s to do with the different threads.

I tried this by then calling the method from another thread in my test app, and it did indeed break it. So. It seems that I can’t use a shutdown hook to do it. Any other ideas?

Is there something I should be doing to tell the JVM to free all the memory that the libraries it has opened are using?

I’m thinking that there is a memory leak (although I can’t find it) in the lib/jni/java interface that is holding on to the event structure. So when the app quits, it’s left around and the device still has it. If I call my own cleanup from the thread that created it, then it seems to clear fine, but I call my clear up from some other thread, then it hangs around.

Endolf

#5

Is the event object native or java side? If native, is it an object or a structure?

Kev

#6

Hi

It’s a struct in the native code, not a pointer to one.

Endolf

#7

Hi

Right, ok, this is wierd, although the native stuff is in a shared lib, the java thread you call the methods from seems to effect things. For example, if I init the event interface layer from one thread, I also have to call the rumble methods from that same java thread, otherwise I get a permission denied error. If I call my cleanup code, it leaves effects in the device memory.

I’ve only made modifications to the event interface layer, not the joystick layer, so USB devices work now, but there is no support for the old 15 pin style devices. The outcome of the poll will decide if I need to do more work to get them both working, or if I just merge in the stuff I have.

Endolf

#8

Hmm, this sounds like very Linux specific behavior and I’m afraid I can’t help much :confused:

if it were Windows I’d slap you for tring to do anything that calls DX fromdifferent threads, WIndows hates that. (Its still a monothreaded operating system, it just prentends on the suer level that it isn’t.)