/*
(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
  xxxxx@xxxxx  


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

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

  xxxxx@xxxxx   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).

  xxxxx@xxxxx   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.

  xxxxx@xxxxx   2001-04-17

I have been informed that this problem may be related
to bug 4363638 which seems to suggest that COBOL's use of signal handlers
may be relate to this problem.

In my *real* program (rather than the testcase above) the C code is part
of our TRANS transaction processing system. This system additionally has a 
requirement to use *its own* signal handlers which may further complicate
matter for us. If this does turn out to be signal handler related, we would appreciate
advice on how to invoke HotSpot from a C program that additionally needs to 
catch signals.

I have retested this issue with the FCS version of JDK1.3
on Solaris 8 and the problem still occurs.

$ java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 
1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)