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)

I am trying to start the JVM using JNI, from a C shared library which is loaded
by using the "dlopen" call by an executable called "rttsee".

Both rttsee and shared library are linked with -lpthread.

Here is the code snippet from the library, used for starting the JVM:

****************************************************************
#define STR_JAVA_TWO_JVM "libjvm.so"

int InitializeJVM()
{
        void *libVM;
        BOOL bIsJavaTwo = TRUE;
        char buf[CLASSPATH_BUF_SIZE];
        jint res;
        char *rt_jvm_minheap;
        char *rt_jvm_maxheap;

        // Try Java two (1.2, 1.3) first for performance reasons
        libVM = dlopen(STR_JAVA_TWO_JVM, RTLD_LAZY);
        if (libVM == NULL)  // no Java two? Try Java one
        {
                bIsJavaTwo = FALSE;
                libVM = dlopen(STR_JAVA_ONE_JVM, RTLD_LAZY);
        }
        if (libVM == NULL) // we're toast, no recovery possible
                return FALSE;

        rt_jvm_minheap = (char *)getenv("RT_JVM_MINHEAP");
        rt_jvm_maxheap = (char *)getenv("RT_JVM_MAXHEAP");

        if (bIsJavaTwo)
        {
        typedef int (*func)(JavaVM**, JNIEnv**, JavaVMInitArgs*);
            JavaVMOption options[2];
            func fpJNI;
            JavaVMInitArgs vm_args;
            char rthome[MAX_PATH];
            char minheapstr[80] = "";
            char maxheapstr[80] = "";

            fpJNI = dlsym(libVM, "JNI_CreateJavaVM");
                // Create the Java 1.2 or greater JVM
                vm_args.version = 0x00010002;
                vm_args.options = options;
                vm_args.nOptions = 2;
                vm_args.ignoreUnrecognized = JNI_TRUE;
                GetResolveClasspath(buf, CLASSPATH_BUF_SIZE, bIsJavaTwo);
                options[0].optionString = buf;
                strcpy(rthome, "-Drt.home=");
                strcat(rthome, getenv("RTHOME"));
                options[1].optionString = rthome;
                if (rt_jvm_minheap)
                {
                    sprintf(minheapstr, "-Xms%s", rt_jvm_minheap);
                    options[2].optionString =  minheapstr;
                    vm_args.nOptions=3;
                }
                if (rt_jvm_maxheap)
                {
                    sprintf(maxheapstr, "-Xmx%s", rt_jvm_maxheap);
                    options[3].optionString = maxheapstr;
                    vm_args.nOptions=4;
                }
                res = fpJNI(&gbJvm, &gbEnv, &vm_args);
        }
************************************************************************

The Java 2 JVM library is found successfully, it's the JVM kickoff that fails.

I am getting the folowing error:
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Error ID: 4F533F4C494E55580E4350500570
#
# Problematic Thread: rttsee: fatal program initialization error:
[23.3.9.2]: Received SIGSEGV signal

The link statement to make the library is:
gcc -export -shared -lpthread -static -L../../../linux_stage/pvt/lib/rel -lrttss
 -lrtmsgc -ltmsconfiguration -lrtlogio -L/usr/lib/gcc-lib/i386- customer -linux/egcs
-2.91.66 -lstdc++ -lgcc -L/usr/java/jdk1.3/jre/lib/i386/client -ljvm  rttseajava.o -o ../../../linux_stage/pvt/prod/rel/TSEA/rttseajava.so

It all worked OK with sdk1.2.2, and it fails with 1.3
(Review ID: 113522) 
======================================================================

N/A

Andrew or Olav,

	I'm looking into bug 4397350, but I will need a small testcase to reproduce this for you.
Once I have the testcase I can work on getting this bug assigned as an issue.

Bug description:
***********************************************************
I am trying to start the JVM using JNI, from a C shared library which is loaded
by using the "dlopen" call by an executable called "rttsee".

Both rttsee and shared library are linked with -lpthread.
***********************************************************
email sent to above....
  xxxxx@xxxxx   2000-12-15

Olav,

Thanks for your reply, however, I am in need of some more info. At this point I
can not get enough details to help look into this problem for you.  If I download
ColdFusion 4.5.1 sp2 for solaris, could you then send me steps to reproduce your 
problem?


  xxxxx@xxxxx   2000-12-19

After a good amount of time I able to narrow down this to a VM runtime error. At least that is what I think.. When running ColdFusion App with jdk1.2.2_06 all is fine, but when you run it with a Hotspot VM, 1.3.1 oor 1.4 on any platform we die in initialization of the args ThreadCreateLocalStorage. I think the problem is with the Coldfusion app passing args that are not recognized by hotspot, but even if that is true we should not core dump/SIGSEGV. The app may have been designed for ExactVM!!!

Stack trace:
"Fatal","TID=1","12/19/00","16:37:16","Caught a fatal signal (11) - Aborting"
2559:   /opt/coldfusion/bin/cfserver
-----------------  lwp# 1 / thread# 1  --------------------
 fe49a5ac waitid   (0, a01, ffbee328, 103)
 fe454d88 _waitpid (0, ffbee410, 100, ffbee410, 3, ffbee479) + 60
 fe490134 system   (ffbee5e8, 947aa8, 9ff, 947a8c, 947a7c, 3) + 204
 00328480 CrashHandler (947a8c, 947a44, ffbef020, fe5ee000, b0f6b8, b0f6a8) + 10c
 fe5d90b0 __libthread_segvhdlr (b, ffbef2d8, ffbef020, fe5ee000, b, 0) + e4
 fe5dbc20 __sighndlr (b, ffbef2d8, ffbef020, fe5d8fcc, b0f6b8, b0f6a8) + c
 fe5d8424 sigacthandler (b, b0f620, ffbef020, fe5ee000, b0f620, ffbef2d8) + 6e0
 --- called from signal handler with signal 11 (SIGSEGV) ---
 fce58fac __1cSThreadLocalStorageUget_thread_via_cache6F_pnGThread__ (f09b48, 1b8, b0c888, b0c888, 1b8, f09b48) + 84
 fca9f4e4 __1cSThreadLocalStorageGthread6F_pnGThread__ (f09b60, b961c0, 2, 0, 0, 0) + 54
 fca9f114 __1cGThreadHcurrent6F_p0_ (f09b60, fd3dd388, b0ec28, b0c888, 34, b96230) + 24
 fca9d888 __1cUGenericGrowableArray2t6Mil_v_ (b440d8, 64, 1, 0, 0, 0) + 188
 fcaa8dac __1cNGrowableArray4CpnQHistogramElement__2t5B6Mil_v_ (b440d8, 64, 1, 0, 0, 0) + 44
 fcaa870c __1cJHistogram2t6Mpkci_v_ (b96248, fd3ffe5c, 64, 0, 0, 0) + 94
 fcb612e0 __1cTJNIHistogramElement2t6Mpkc_v_ (b961a0, fd412de4, 0, 0, 0, 0) + b0
 fcb96ab0 JNI_GetCreatedJavaVMs (b6ca18, 1, ffbef93c, fcb96a28, 17908, 0) + 88
 fe731494 __1cHCJavaVMGattach6M_C_ (fe793fd4, b6ca10, fe281410, 0, b6ce7c, ffbefaf0) + a4
 0027377c __1cPCJvmInitializerJgetJavaVM6M_rnHCJavaVM__ (ac0400, fcb96a28, 0, ffbefafc, b6ca10, fcb96820) + 320
 00273410 __1cPCJvmInitializerMgetJNIJavaVM6M_pnHJavaVM___ (b6ca10, 0, 0, 9339e6, 0, fe4a208c) + 4
 00291b3c ???????? (b79d18, 9339e4, 0, ffbefc1c, ac1df0, f0)
 00290bd8 __1cNWebServerInit6Fi_v_ (b49b60, b49b60, ad5df0, fe5ee000, 4, ffbefdc8) + 154
 0032769c __1cKServerInit6FirnHCString_i_i_ (0, ffbefdb4, 0, fe5ee000, 4, b0f6a8) + 14
 00328074 __1cMCWebFrameAppMInitInstance6M_i_ (ad6c00, b05800, b058bc, 0, 6, 100000) + 104
 002a11fc main     (20, ffbefeac, ffbefeb4, ab2000, 0, 0) + 74
 001d3608 _start   (0, 0, 0, 0, 0, 0) + b8
-----------------  lwp# 2 / thread# 2  --------------------
 fe4999e8 signotifywait ()
 fe5ce920 _dynamiclwps (fe5ee000, 5c, 0, 0, 0, 0) + 1c
 fe5d1c78 thr_yield (0, 0, 0, 0, 0, 0) + 8c
-----------------  lwp# 3  --------------------------------
 fe499fcc lwp_cond_wait (fe5f55c8, fe5f55d8, fe4d5bf0)
 fe491c88 _lwp_cond_timedwait (0, 3a3fd638, fe4d5c58, fe5f55c8, fe5f55d8, 0) + 98
 fe5c8e18 _age     (fe5eedc0, fe5eedc4, fe5ee000, 0, 0, 4) + 94
 fe497608 _door_return (fe5ef6d0, 3, fe5ee000, 1, fe4d5cb8, fe5ca440) + 68
-----------------  lwp# 4 / thread# 4  --------------------
 fe496a28 nanosleep (fde0bcb0, 0)
 fe670670 __1cHSleepEx6FLi_L_ (1b7740, 0, 0, ffffff10, 0, b0ef41) + a8
 002914ec ???????? (0, ac1ddc, 1, fe5fae04, 0, 2)
 fe5dbb24 _thread_start (0, 0, 0, 0, 0, 0) + 40
-----------------  lwp# 5 / thread# 6  --------------------
 fe496a28 nanosleep (fdd09ab8, 0)
 fe670670 __1cHSleepEx6FLi_L_ (3e8, 0, 0, 2, fdd09b7c, 5) + a8
 0032b07c __1cMBTLoadUpdate6Fpv_0_ (fdd09b68, ad62a0, 32ab28, 948265, 3e8, ad6c24) + 534
 fe5dbb24 _thread_start (0, 0, 0, 0, 0, 0) + 40
-----------------  lwp# 6  --------------------------------
 fe4975ac door     (0, 0, 0, 0, fe345d18, 4)
 fe5ca440 _lwp_start (fe345d78, 0, 6000, fe4d5b7c, 0, 0) + 18
 fe5d1c78 thr_yield (0, 0, 0, 0, 0, 0) + 8c
-----------------  lwp# 7  --------------------------------
 fe499fcc lwp_cond_wait (fe5f55c8, fe5f55d8, fe333c48)
 fe491c88 _lwp_cond_timedwait (0, 3a3fd638, fe333cb0, fe5f55c8, fe5f55d8, 0) + 98
 fe5c8e18 _age     (fe5eedc0, fe5eedc4, fe5ee000, 3, fe5ee000, 1) + 94
 fe5ca440 _lwp_start (fe333d78, 0, 4000, ffbefc3c, 0, 0) + 18
 fe5d1c78 thr_yield (0, 0, 0, 0, 0, 0) + 8c
-----------------  lwp# 8  --------------------------------
 fe499fcc lwp_cond_wait (fe5f55c8, fe5f55d8, fe323c48)
 fe491c88 _lwp_cond_timedwait (0, 3a3fd638, fe323cb0, fe5f55c8, fe5f55d8, 0) + 98
 fe5c8e18 _age     (fe5eedc0, fe5eedc4, fe5ee000, 3, fe5ee000, 1) + 94
 fe5ca440 _lwp_start (fe323d78, 0, 4000, ffbefc3c, 0, 0) + 18
 fe5d1c78 thr_yield (0, 0, 0, 0, 0, 0) + 8c
-----------------  lwp# 9  --------------------------------
 fe499fcc lwp_cond_wait (fe5f55c8, fe5f55d8, fe313c48)
 fe491c88 _lwp_cond_timedwait (0, 3a3fd638, fe313cb0, fe5f55c8, fe5f55d8, 0) + 98
 fe5c8e18 _age     (fe5eedc0, fe5eedc4, fe5ee000, 3, fe5ee000, 1) + 94
 fe5ca440 _lwp_start (fe313d78, 0, 4000, ffbefc3c, 0, 0) + 18
 fe5d1c78 thr_yield (0, 0, 0, 0, 0, 0) + 8c
-----------------  lwp# 10  --------------------------------
 fe499fcc lwp_cond_wait (fe5f55c8, fe5f55d8, fe303c48)
 fe491c88 _lwp_cond_timedwait (0, 3a3fd638, fe303cb0, fe5f55c8, fe5f55d8, 0) + 98
 fe5c8e18 _age     (fe5eedc0, fe5eedc4, fe5ee000, 3, fe5ee000, 1) + 94
 fe5ca440 _lwp_start (fe303d78, 0, 4000, ffbefc3c, 0, 0) + 18
 fe5d1c78 thr_yield (0, 0, 0, 0, 0, 0) + 8c
-----------------  lwp# 11  --------------------------------
 fe499fcc lwp_cond_wait (fe5f55c8, fe5f55d8, fe2f3c48)
 fe491c88 _lwp_cond_timedwait (0, 3a3fd638, fe2f3cb0, fe5f55c8, fe5f55d8, 0) + 98
 fe5c8e18 _age     (fe5eedc0, fe5eedc4, fe5ee000, 3, fe5ee000, 1) + 94
 fe5ca440 _lwp_start (fe2f3d78, 0, 4000, ffbefc3c, 0, 0) + 18
 fe5d1c78 thr_yield (0, 0, 0, 0, 0, 0) + 8c
-----------------  lwp# 12  --------------------------------
 fe499fcc lwp_cond_wait (fe5f55c8, fe5f55d8, fe2e3c48)
 fe491c88 _lwp_cond_timedwait (0, 3a3fd638, fe2e3cb0, fe5f55c8, fe5f55d8, 0) + 98
 fe5c8e18 _age     (fe5eedc0, fe5eedc4, fe5ee000, 3, fe5ee000, 1) + 94
 fe5ca440 _lwp_start (fe2e3d78, 0, 4000, ffbefc3c, 0, 0) + 18
 fe5d1c78 thr_yield (0, 0, 0, 0, 0, 0) + 8c
--------------------------  thread# 3  --------------------
 fe5cd8d8 _reap_wait (fe5f2a30, fe5ee000, 0, 5, 0, 5) + 38
 fe5cd630 _reaper  (fe5eee58, fe5f4798, fe5f2a30, fe5eee30, 1, fe400000) + 38
 fe5dbb24 _thread_start (0, 0, 0, 0, 0, 0) + 40


  xxxxx@xxxxx   2000-12-19

After a little more configuration changes I found that it was a config issue.
Path to JVM was the issue. I can now use 1.3.0, 1.3.1, 1.4 JDK as well as 1.2.2_06.  Closing as not a bug but rather a config issue.

JVMPath:                /disk/j2sdk1_3_0/jre/lib/sparc/libjvm.so;	REG_SZ
  xxxxx@xxxxx   2001-01-02

Customer did not have LD_LIBRARY_PATH set correctly.  He was trying to run
server version of the JVM but did not provide path to the libjvm.so in the LD_LIBRARY_PATH

Olav,

After looking at your start script I see where there may be a mistake.

This is yours:

JAVA_HOME=/opt/j2sdk1.3.0
LD_LIBRARY_PATH=$CFHOME/lib:$ORACLE_HOME/lib:$JAVA_HOME/lib/i386:$JAVA_HOME/jre/lib/i386:$JAVA_HOME/jre/lib/i386/native_threads


Try this one: 

JAVA_HOME=/opt/j2sdk1.3.0
LD_LIBRARY_PATH=$CFHOME/lib:$ORACLE_HOME/lib:$JAVA_HOME/lib/i386/server:$JAVA_HOME/jre/lib/i386/native_threads:$JAVA_HOME/jre/lib/i386

In the above notice server at the end on the path for first LD_LIBRARY_PATH.. You were missing the
vital path here.

Please read on for future issues when switching between JVMs, client,server, classic, etc....


I think I finally got to the bottom of this. In your start script
ColdFusion requires you to set LD_LIBRARY_PATH for your new JDK.

i.e.

Client 1.3.0 & 1.3.1 & 1.4 

start script: 
LD_LIBRARY_PATH=$CFHOME/lib:/pathtoyourJDK/1.3.1/linux/jre/lib/i386/client:/pathtoyourJDK/1.3.1/linux/jre/lib/i386/native_threads:/pathtoyourJDK/1.3.1/linux/jre/lib/i386

JVMPath:                /pathtoyourJDK/1.3.1/linux/jre/lib/i386/client/libjvm.so; REG_SZ


or 

Server  1.3.0 & 1.3.1 & 1.4 

start script:
LD_LIBRARY_PATH=$CFHOME/lib:/pathtoyourJDK/1.3.1/linux/jre/lib/i386/server:/pathtoyourJDK/1.3.1/linux/jre/lib/i386/native_threads:/pathtoyourJDK/1.3.1/linux/jre/lib/i386

JVMPath:                /pathtoyourJDK/1.3.1/linux/jre/lib/i386/server/libjvm.so; REG_SZ




  xxxxx@xxxxx   2001-01-08

Customer Andrew Hoppe:
Hi Gary,

I think I finaly nailed this problem down to the
1.3 JVM on Solaris and Linux failing to start from
the JNI code if the C code sets the SIGSEGV signal handler.

I have attached 3 files, called c, test.c and testm.c

The one called "c" contains commands to compile the 
"testm.c" file to a.out, and "test.c" to a shared library "libtest.so";

test.c contains function called "InitializeJVM" which calls
JNI_CreateJavaVM(),

testm.c contains main which loads libtest.so and locates and calls
InitializeJVM.

Run "sh c" to obtain a.out and libtest.so, and then run a.out
It fails on both Solaris and Linux, on Solaris it SIGSEGV's
and on Linux it loops.

If you remove line # 74 from testm.c (signal call)and recompile
it works fine on both Solaris and Linux.

Am I missing something about setting signal handlers with JNI,
or is it a JVM bug? It worked fine with JDK 1.1.7 and 1.2.2

We would like to have our own signal handler
and the same C code for all JDKs.

Thanks for any response

Andrew

Andrew Hoppe
Staff Software Engineer
Rational Software               
8521 Six Forks Road, Suite 200
Raleigh, NC 27615
tel. (919) 845-3227
email:   xxxxx@xxxxx  
www.rational.com




-----Original Message-----

[mailto:  xxxxx@xxxxx  -george.East.Sun.COM]
Sent: Friday, December 15, 2000 4:18 PM

  xxxxx@xxxxx  -george.East.Sun.COM

Subject: bug: 4397350 Synopsis:REGRESSION:can't start 1.3 JVM from C
shared lib loaded using "dlopen": worked i


Andrew or Olav,

	I'm looking into bug 4397350, but I will need a small testcase to
reproduce this for you.
Once I have the testcase I can work on getting this bug assigned as an
issue.

Bug description:
***********************************************************
I am trying to start the JVM using JNI, from a C shared library which is
loaded
by using the "dlopen" call by an executable called "rttsee".

Both rttsee and shared library are linked with -lpthread.
***********************************************************

Thanks in advance for any help you can provide,
Gary Collins -- JavaSoft Engineering


The issue with coldfusion is a config issue. If user sets 
ImplementationOptions:  -XX:+AllowUserSignalHandlers;    REG_SZ

Linux was able to invoke a JVM from coldfusion.

That's it!?!

Yes, it now runs. Incredible, I had written this thing off as an
impossibility. Well done!

And tell me, is this option documented anywhere? I can't find any docs on
it...


We're grateful. Thanks.


With regards,
Olav


  xxxxx@xxxxx   2001-01-11

i want to call java method into c file .
 want command to compile the c file with gcc
pl write me the gcc command and also necessary path 
i should set.

 want to call java method into c file .
  want command to compile the c file with gcc
   pl write me the gcc command and also necessary path 
    i should set. 
my emailid is raj_ind72@rediffmail.com