JDK-4366535 : JDK 1.3 HotSpot crashes when linked with Merant COBOL libs
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.0
  • Priority: P1
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_7,solaris_8
  • CPU: sparc
  • Submitted: 2000-08-29
  • Updated: 2001-04-17
  • Resolved: 2001-04-17
Related Reports
Duplicate :  
Relates :  
Description

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) 
======================================================================

Comments
WORK AROUND Name: tb29552 Date: 08/28/2000 None known. The classic VM is not shipped with JDK1.3 on Solaris, and in any case the Classic VM has problems when used with dynamic load (dlopen() etc) which prevent me from using it. ======================================================================
11-06-2004

EVALUATION y.s.ramakrishna@eng 2000-11-21: The JDDK 1.2.2 production VM will have similar problems, since the application's native libraries are installting handlers for SEGV and BUS, which are used by the JVM. There is no current quick fix for this problem, but this will be addressed for Merlin, see RFE 4381843 (signal filtering and chaining). y.s.ramakrishna@eng 2001-01-29: Mingyao Yang is implementing this functionality as part of RFE 4381843; making him RE. The bug reported in this report was verified to be a duplicate of 4363638. However it's potentially possible that Java vm is created first and loads a native libarary which has dependency on Merant COBOL lib. The .init sections of some Merant COBOL libs try to install signal handlers for some signals used by the hotspot vm. To fix this scenario, interposition of sigaction() is needed and will be implemented as part of RFE 4381843. mingyao.yang@Eng 2001-04-17
17-04-2001