title: JNI CallObjectMethod screws up the stack frame?
body: <p>I have C++ code invoking a Java method that returns an object:</p>
  
  <pre><code>virtual bool OnGetData(sf::SoundStream::Chunk&amp; data) {
      jobject jchunk = env-&gt;CallObjectMethod(binding, JSoundStream::m_getData);
      if(jchunk) {
              //... some processing code will go here in the future
              return true;
      }
      return false;
  }
  </code></pre>
  
  <p>This method lies inside of a C++ class where <code>binding</code> is a valid global Java object reference and <code>JSoundStream::m_getData</code> is the method ID of the following method inside of the following Java class:</p>
  
  <pre><code>public class TestStream extends JSoundStream {
      [...]
  
      @Override
      public Chunk getData() {
          return null; //testing
      }
  }
  </code></pre>
  
  <p>I <em>randomly</em> 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 <code>CallObjectMethod</code> 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.</p>
  
  <p>The question now is: <em>what</em> 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.</p>
  
  <p>My C++ code is compiled using the <code>__cdecl</code> calling convention (which is required for a linking to a key library I'm using), and JNI methods use <code>__stdcall</code>, 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?</p>