2 Replies Latest reply on Jun 5, 2012 12:37 AM by jschellSomeoneStoleMyAlias

    JVM crash with 64bit JNI Windows


      I am trying to create a 64bit version of yaz4j and so far I am unable to get this to work.
      I have managed to build a dll but any calls to the functions crashes the JVM.

      I have previously built yaz4j for Windows 32bit/Mac 32bit and 64bit/Linux so just followed the same approach to get
      this running on Windows 64bit. Currently I am using 64bit gcc v4.5.3 installed via cygwin. All other
      dependent dlls are 64bit.

      Reading a few forum posts, the suggestion is that this is caused by an exception being thrown in native code and the JVM not knowing what to do with it.
      The yaz4j code is C so there are no exceptions being thrown.

      # A fatal error has been detected by the Java Runtime Environment:
      # Internal Error (os_windows_x86.cpp:149), pid=5736, tid=9928
      # guarantee(result == EXCEPTION_CONTINUE_EXECUTION) failed: Unexpected result from topLevelExceptionFilter
      # JRE version: 6.0_32-b05
      # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.7-b02 mixed mode windows-amd64 compressed oops)
      # An error report file with more information is saved as:
      # C:\Y\2\hs_err_pid5628.log
      # If you would like to submit a bug report, please visit:
      # http://java.sun.com/webapps/bugreport/crash.jsp
      # The crash happened outside the Java Virtual Machine in native code.
      # See problematic frame for where to report the bug.

      Looking at the pid file:

      --------------- T H R E A D ---------------

      Current thread (0x00000000001db800): JavaThread "main" [_thread_in_native, id=9928, stack(0x0000000002020000,0x0000000002120000)]

      Stack: [0x0000000002020000,0x0000000002120000]
      [error occurred during error reporting (printing stack bounds), id 0xe0000000]

      [error occurred during error reporting (printing native stack), id 0xe0000000]

      Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
      j org.yaz4j.jni.yaz4jlibJNI.ZOOM_connection_create(J)J+0
      j org.yaz4j.jni.yaz4jlib.ZOOM_connection_create(Lorg/yaz4j/jni/SWIGTYPE_p_ZOOM_options_p;)Lorg/yaz4j/jni/SWIGTYPE_p_ZOOM_connection_p;+4
      j org.yaz4j.Connection.<init>(Ljava/lang/String;I)V+26
      j Yaz4J_Test2.Connect(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;I)I+44
      j Yaz4J_Test2.main([Ljava/lang/String;)V+52
      v ~StubRoutines::call_stub

      --------------- T H R E A D ---------------

      If anyone has any suggestions, it would be appreciated.

        • 1. Re: JVM crash with 64bit JNI Windows
          user3491646 wrote:
          If anyone has any suggestions, it would be appreciated.
          Yes this is a native crash, meaning something went wrong in the native code.

          So that already instantly makes it so it isn't a question for this forum. I hope you have facilities to be able to debug that DLL of yours. If I would have to develop a native library for a java app I'd do three things in that order:

          - be 100% positive I need a native library
          - double check that it has to be a native library and there is no pure java solution
          - make it so I can develop the DLL by invoking it from a native application; then when it is working as expected try to hook it up to Java code through JNI/JNA

          Of course you have one piece of valuable information:
          Apparently things don't go so well on this connection_create() function.
          • 2. Re: JVM crash with 64bit JNI Windows
            user3491646 wrote:
            The yaz4j code is C so there are no exceptions being thrown.
            I suggest you look up "__try" - note that there are two underscores. Folllowing is from my MSDN documentation.

            +"The try-except statement is a Microsoft extension to the *C* language that enables applications to gain control of a program when events that normally terminate execution occur. Such events are called exceptions, and the mechanism that deals with exceptions is called structured exception handling."+