Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4366535

JDK 1.3 HotSpot crashes when linked with Merant COBOL libs

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: P1 P1
    • None
    • 1.3.0
    • hotspot
    • sparc
    • solaris_7, solaris_8



      Name: tb29552 Date: 08/28/2000


      /*
      (h)/java/firsttest java -version
      java version "1.3.0"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-RC)
      Java HotSpot(TM) Client VM (build 1.3.0-RC, mixed mode)


      I have a C program which needs to be able to call both Java and
      COBOL subroutines on Solaris 8. I need to use Java 1.3. The COBOL
      is Merant ServerExpress COBOL 1.0 with fixpack 1.

      I have already raised this issue with Merant, and they are in the
      process of trying to raise it through their Sun representative. I
      am raising this report in order that I can obtain a bug number
      that the Sun representative can refer to.

      The Merant problem report number is 1103334

      Please note I have put in *substantial* effort on this problem in
      order to create the attached *simple* testcase and Makefile.


      We are experiencing a problem starting the Java 1.3.0 virtual
      machine on Solaris 8 when our exectuable is linked with the
      Merant Server Express COBOL runtime.

      Details follow. For more information, please contact
      ###@###.###


      Before building or running the attached testcases, it is
      necessary to set LD_LIBRARY_PATH appropriately, e.g. on my
      machine:

      $ echo $LD_LIBRARY_PATH
      /usr/java1.3.0/jre/lib/sparc:/opt/lib/cobol/lib


      The C code in go.c represents what we want to do in a process
      which is to start the Java VM (in order to call a Java
      subroutine) and then some time later invoke a COBOL
      subroutine. (Note that the call of the COBOL subroutine is
      currently commented out, since in the error case we never get
      that far).

      The source code is build 3 ways:

      1) As an executable 'go' using only the C compiler. When running
      'go' the program runs as expected:

      $ ./go
      Starting
      Creating the JVM ...
      Created JVM OK
      Exiting

      2) As an executable 'go2' compiled with the C compiler, and
      linked using 'cob' to make the COBOL runtime libraries
      available. We are using ServerExpress on Solaris 8. In this case,
      the following output occurs:

      $ ./go2
      Starting
      Creating the JVM ...
      #
      # HotSpot Virtual Machine Error, Internal Error
      # Please report this error at
      # http://java.sun.com/cgi-bin/bugreport.cgi
      #

      Execution error : file ''
      error code: 114, pc=0, call=1, seg=0
      114 Attempt to access item beyond bounds of memory (Signal 11)

      Note that the java 1.3.0 VM fails to start up, and then it
      appears that the COBOL signal handlers are getting invoked.


      3) As ana exectuable 'go3' linked using the C compiler, by
      additionally linking with the COBOL runtime libraries. This
      executable fails in the same way as for 2):

      $ ./go3
      Starting
      Creating the JVM ...
      #
      # HotSpot Virtual Machine Error, Internal Error
      # Please report this error at
      # http://java.sun.com/cgi-bin/bugreport.cgi
      #

      Execution error : file ''
      error code: 114, pc=0, call=1, seg=0
      114 Attempt to access item beyond bounds of memory (Signal 11)



      i.e. Just *linking* with the COBOL libraries cases this problem !


      Note that the problem does *not* seem to occur using the old
      'classic' JVM shipped with Java 1.2.1 on Solaris. This can be
      seen by setting LD_LIBRARY_PATH appropriately and trying to run
      go2 and go2:

      $ echo $LD_LIBRARY_PATH
      /usr/java1.2.1/jre/lib/sparc:/opt/lib/cobol/lib
      $ ./go2
      Starting
      Creating the JVM ...
      Created JVM OK
      Exiting
      $ ./go3
      Starting
      Creating the JVM ...
      Created JVM OK
      Exiting


      It appears that SUN are not shipping the classic VM with Java
      1.3, and so this leaves us no way of calling both COBOL and Java
      subroutines from the same process on Solaris 8.


      -----go.c follows------
      */
      #include <dlfcn.h>
      #include <jni.h>


      void main()
      {
          printf("Starting\n");


          {
              JavaVMInitArgs vmArgs;
              JavaVMOption *vmOptions;
              JavaVM *jvm;
              JNIEnv *jniEnv;
              jint rc;

              vmOptions = (JavaVMOption *)malloc( sizeof(JavaVMOption) * 2 );
              vmOptions[0].optionString = "-Djava.ifl=hello";
              vmArgs.version = JNI_VERSION_1_2;
              vmArgs.options = vmOptions;
              vmArgs.nOptions = 1;
              vmArgs.ignoreUnrecognized = JNI_FALSE;

              printf("Creating the JVM ...\n");
              rc = JNI_CreateJavaVM(&jvm,(void **)&jniEnv,&vmArgs);

              if (rc == 0)
              {
                  printf("Created JVM OK\n");
              }
              else
              {
                  printf("Creation of VM failed rrc=%d\n",rc);
              }
          }

          /*
          ** Eventually, we want to be able to do cobol stuff here
          **
          ** cobfunc(); etc
          */


          printf("Exiting\n");
      }

      --- Makefile with *3* targets follows ---
      all: go go2 go3

      go: go.c
      cc -I/usr/java1.3.0/include -I/usr/java1.3.0/include/solaris -mt -c go.c -o go.o
      cc -mt go.o -o go -lthread -ldl -lc -ljvm



      go2: go.c
      cc -mt -I/usr/java1.3.0/include -I/usr/java1.3.0/include/solaris -c go.c -o go2.o
      cob -t -o go2 go2.o -ljvm




      go3: go.c
      cc -I/usr/java1.3.0/include -I/usr/java1.3.0/include/solaris -mt -c go.c -o go3.o
      cc -mt go3.o -o go3 -lthread -ldl -lc -ljvm -lcobmisc_t -lcobcrtn -lcobrts_t -lrt

      clean:
      rm -f *.o
      rm -f go go2 go3
      rm -f core
      (Review ID: 108918)
      ======================================================================

            myangsunw Mingyao Yang (Inactive)
            tbell Tim Bell
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: