JNI CallObjectMethod screws up the stack frame?

Question

I have C++ code invoking a Java method that returns an object:

virtual bool OnGetData(sf::SoundStream::Chunk& data) {
    jobject jchunk = env->CallObjectMethod(binding, JSoundStream::m_getData);
    if(jchunk) {
            //... some processing code will go here in the future
            return true;
    }
    return false;
}

This method lies inside of a C++ class where binding is a valid global Java object reference and JSoundStream::m_getData is the method ID of the following method inside of the following Java class:

public class TestStream extends JSoundStream {
    [...]

    @Override
    public Chunk getData() {
        return null; //testing
    }
}

I randomly get access violations inside the JVM when that method is called from C++. Sometimes it just works fine, sometimes I get an access violation. Removing the CallObjectMethod line will never cause one, so it must be source of the access violations. Inserting printfs for debug purposes makes those access violations a lot more likely. That rings a bell for me: I'm pretty certain that something is screwing up the stack frame.

The question now is: what might be screwing up the stack frame? I can't find anything suspicious. It must have something to do with the object method call, because removing it gets rid of any problems.

My C++ code is compiled using the __cdecl calling convention (which is required for a linking to a key library I'm using), and JNI methods use __stdcall, but for what I know the compiler (MSVC++ 2008 Express) should be aware of it and take care of "conversion", so I doubt this is the problem. If it is, how would I solve this conflict? If it is not, what is?

Answer 1

It is probably the env pointer that you are using. You must attach the JVM to the current thread by calling jvm->AttachCurrentThread(&env); where the jvm pointer has been cached.