205520 - LiveConnect error with JDK 1.3.1+ : Failed to create Java VM

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Java: Live Connect, defect)

Description

[Tim Colles]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030429
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030429

I am having trouble getting the current standalone version of JS/LC working.
Version 1.5-rc4a was working fine with version 1.2.2 of the Java SDK, but
version 1.5-rc5 from ftp://ftp.mozilla.org/pub/js/) seems to be broken
with the Java SDK 1.4.1 from Sun (I haven't tried it against an earlier SDK
yet). When I compile it throws up the following warnings doing liveconnect:

jsj_simpleapi.c: In function `default_create_java_vm':
jsj_simpleapi.c:106: warning: passing arg 2 of `JNI_CreateJavaVM' from
incompatible pointer type
jsj_simpleapi.c: In function `default_attach_current_thread':
jsj_simpleapi.c:127: warning: passing arg 2 of pointer to function from
incompatible pointer type

and then when I run lcshell for example it just bombs out with the "Failed to
create Java VM" error. Looking at the source the error is subsequent to the
code generating the warnings above.

Has anyone else seen this?

Is it a JS/LC problem, or a problem with the Java SDK, or some problem with my
local setup?

Compilation is under Linux RH7.1/3ish BTW if thats of any importance.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Phil Schwartau]

I don't think it has anything to do with updating to version 1.5-rc5 of JS,
but rather, updating from Java JDK 1.2.2 to JDK 1.4.1. 

I think you have to locally adjust your LiveConnect config file:
http://lxr.mozilla.org/mozilla/source/js/src/liveconnect/config/Linux_All.mk:

The default build parameters are:

-----------------------------------------------------------------------
ifndef JDK_VERSION
JDK_VERSION = 1.2.2
endif

JDK = /share/builds/components/jdk/$(JDK_VERSION)/Linux

INCLUDES   += -I$(JDK)/include/linux -I$(JDK)/include

OTHER_LIBS += -L$(JDK)/jre/lib/i386/native_threads
OTHER_LIBS += -L$(JDK)/jre/lib/i386/classic
OTHER_LIBS += -L$(JDK)/jre/lib/i386 -ljava -ljvm -lhpi
-----------------------------------------------------------------------


Tim: what happens if you set JDK_VERSION=1.4.1 when you run make, as in:

[//d/mozilla/js/src/liveconnect] make -f Makefile.ref JDK_VERSION=1.4.1

Of course, you'll have to hack the config file so that this line:

     JDK = /share/builds/components/jdk/$(JDK_VERSION)/Linux

will result in a valid path.

Comment 2

[Tim Colles]

*** Bug 205785 has been marked as a duplicate of this bug. ***

Comment 3

[Tim Colles]

Hi. Thanks, I just tried that. Got exactly the same warning messages during
the compile and it fell over the same way when run. I also got hold of JDK
1.3.1 and tried it against that and it broke in the same way (the config
file has comments suggesting it should work against JDK 1.3.1).

I then got hold of JDK 1.2.2 again and tried rc5 against that. This still
gave the warnings during compilation but lcshell worked fine when run.

So it looks like JDK 1.3.1+ has changed something such that there is now
an incompatibility.

Comment 4

[Phil Schwartau]

Tim: thank you for your research into this. I will try the same
and report back -

Comment 5

[Bob Clary [:bc] (inactive)]

I bet this has to do with this code in jsj_simpleapi.c

static JSBool JS_DLL_CALLBACK
default_create_java_vm(SystemJavaVM* *jvm, JNIEnv* *initialEnv, void* initargs)
{
    jint err;
    const char* user_classpath = (const char*)initargs;
    char* full_classpath = NULL;

    /* No Java VM supplied, so create our own */
    JDK1_1InitArgs vm_args;
    memset(&vm_args, 0, sizeof(vm_args));

    /* Magic constant indicates JRE version 1.1 */
    vm_args.version = 0x00010001;
    JNI_GetDefaultJavaVMInitArgs(&vm_args);

Comment 6

[Alfred Peng]

Attachment: Possible fix for Solaris/Linux

I also add two files for Solaris platform. Maybe because I don't have the write permission for the js module, I can't make them into the patch. Post them separately later on.

I tried this patch on the latest Solaris and Ubuntu. Both platforms can build successfully. After adding some library path to the LD_LIBRARY_PATH on Solaris: (...)/mozilla/js/src/SunOS5.11_DBG.OBJ:/usr/java/jre/lib/sparc/, the lcshell can be startup with a warning: "initialization error: Can't load class netscape/javascript/JSObject". That means there are some problems in the call from Java to Javascript. Anyone know about the reason for this error?

The call from Javascript to Java is still working. The "Sample LiveConnect shell interactions" in the README.html page run pretty well except "Public Method/field enumeration". There is an "InternalError: Java class java.io.PrintStream has no public field or method named "__iterator__" for the enumeration which I think it's fine.

On Ubuntu, it's almost the same.

If someone can help me verify the patch or give me some hint about the error in the call from Java to Javascript, that will be great:-)

BTW, who should I ask for review?

Comment 7

[Alfred Peng]

Attachment: New file1 for Solaris

Comment 8

[Alfred Peng]

Attachment: New file 2 for Solaris

Comment 9

[Alfred Peng]

Attachment: Patch v2 for Solaris/Linux

This patch fixes the problem within the call from Java to Javascript. The root cause is that the "InitArgs" for creating a new JVM has been changed since JNI 1.2.

The changes in the patch:
1. The header dependency(jni.h, prtypes.h). In my opinion, the liveconnect shell should depend on the firefox header installed in the system directory. So I make the change in the patch accordingly by using pkg-config. I'm not sure whether it will influence other platforms except Solaris(Sparc/X86) and Linux(Ubuntu).

If we want to build liveconnect shell with Firefox 2.0, the patch for bug 333738 should be also backport in the 1.8.1 branch to upgrade the jni.h header file.

2. There is a assemble file for Solaris Sparc(lock_SunOS.s). It doesn't work for Solaris x86. So I change the Makefile.ref to differentiate them. At the same time, move the file lock_SunOS.s to lock_SunOS_sun4u.s and make a new file lock_SunOS_i86pc.s to define the function js_CompareAndSwap. I'll post it later. The question is when this function will be used?

3. Removed the linkage to fdlibm library. Is this library useful?

4. Add exception information printing to LOAD_CLASS.

5. To make liveconnect shell work on the latest Solaris x86, I also add two config file js/src/config/SunOS5.11_i86pc.mk and js/src/liveconnect/config/SunOS5.11_i86pc.mk which are the same with Sparc platform.

Since different Linux distros may install java under different directories, the Linux_All.mk may need to be changed on different Linux distros. Or we need a better solution for them.

Comment 10

[Alfred Peng]

Attachment: The assemble file for Solaris x86

Comment 11

[Brendan Eich [:brendan]]

Comment on attachment 249237 [details]
The assemble file for Solaris x86

The license header should be the modern MPL1.1 with GPL/LGPL options, see http://www.mozilla.org/MPL/boilerplate-1.1/.

Just curious: is there no way to do this (efficiently, or at all) with asm in jslock.c?

/be

Comment 12

[Brendan Eich [:brendan]]

Comment on attachment 249236 [details] [diff] [review]
Patch v2 for Solaris/Linux

Looks ok to me, wondering whether timeless has any thoughts.

Alfred, can you coordinate with a Linux guy to see how this works on Fedora or Ubuntu?  I'd ask for a review but I'm not sure whom I should ask.

/be

Comment 13

[Alfred Peng]

Attachment: The assemble v2 for Solaris x86

Brenda, the current Forte also supports this kind of asm in c, but it's not reliable. It's recommended that we make it in a separate assemble file.

As for the different Linux distros, I'll try to ping them.

Comment 14

[Alfred Peng]

Sorry for the typo, Brendan. And thanks for Bob to point that out.

Comment 15

[timeless]

Comment on attachment 249236 [details] [diff] [review]
Patch v2 for Solaris/Linux

-LIB_ASFILES := $(wildcard *_$(OS_ARCH).s)
+LIB_ASFILES := $(wildcard *_$(OS_ARCH)_$(OS_CPUARCH).s)

this would make me happy

this is strange:
+JAVA_HEADER = $(shell pkg-config --cflags firefox-plugin)

this is stranger:
-OTHER_LIBS += -L$(DEPTH)/fdlibm/$(OBJDIR) -lfdm -L../$(OBJDIR) -ljs
+OTHER_LIBS += -L../$(OBJDIR) -ljs

this seems unrelated but probably good:
+            if ((*jEnv)->ExceptionOccurred(jEnv)) {                          \
+                (*jEnv)->ExceptionDescribe(jEnv);                            \
+            }                                                                \

not magical anymore, please remove obsolete comment:
     /* Magic constant indicates JRE version 1.1 */
-    vm_args.version = 0x00010001;
+    vm_args.version = JNI_VERSION_1_1;

this trades one strange thing for a hard coded thing, not great:
-JDK = /share/builds/components/jdk/$(JDK_VERSION)/Linux
+#JDK = /share/builds/components/jdk/$(JDK_VERSION)/Linux
+JDK = /usr/lib/jvm/java-1.5.0-sun

this is correct for solaris:
+PROCESSOR = $(shell uname -p)

and makes me happy :)

Comment 16

[Alfred Peng]

(In reply to comment #15)
> this is strange:
> +JAVA_HEADER = $(shell pkg-config --cflags firefox-plugin)
> 
LC depends on the header file jni.h in /usr/include/firefox/java(The path on Solaris).

> this is stranger:
> -OTHER_LIBS += -L$(DEPTH)/fdlibm/$(OBJDIR) -lfdm -L../$(OBJDIR) -ljs
> +OTHER_LIBS += -L../$(OBJDIR) -ljs
> 
I mentioned this in comment 9. The fdm library seems to be unnecessary.

> this trades one strange thing for a hard coded thing, not great:
> +JDK = /usr/lib/jvm/java-1.5.0-sun
> 
This is the JDK path on Ubuntu on my machine. It works fine. Anyway, I think it's better to replace the version number with $(JDK_VERSION) here.

I'm not sure how is the situation for Fedora. callion, is the Jva path on Fedora different?

Comment 17

[Brendan Eich [:brendan]]

Comment on attachment 249333 [details]
The assemble v2 for Solaris x86

Not a patch, and I'm not up on Sun x86 asm rules, but rs=me assuming it is tested.

Note well that JS_USE_ONLY_NSPR_LOCKS is forced on in jslock.h now due to bug 353962, so you will have to remove that #define to test, and pound on multiple threads somehow, perhaps by running Firefox and the Google Toolbar.

/be

Comment 18

[Alfred Peng]

No response from other Linux distros yet. I'll give it a try on Solaris and Ubuntu anyway. Can I land the patch then? Or I need to get some approval?

Comment 19

[Benjamin Smedberg]

Firefox code moved from custom Liveconnect code to the NPAPI/NPRuntime bridge a while back. Mass-closing the bugs in the liveconnect component which are likely invalid. If you believe that this bug is still relevant to modern versions of Firefox, please reopen it and move it the "Core" product, component "Plug-Ins".