100151 - ProxyJNI Crashes when |netscape.oji.ProxyClassLoaderFactory| is missing

Status: VERIFIED FIXED

(Core Graveyard :: Java: OJI, defect)

Description

[java designer]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913
BuildID:    2001091303

. type javascript: in the URL window
2. In the js console, type:
var x = new Packages.java.lang.Integer(5)

The browser crashes. The crash does not even invoke Talkback.

This is with the latest JRE 1.3.1_01 on Win 2000

Reproducible: Always
Steps to Reproduce:
1. type javascript: in the URL window
2. In the js console, type:
var x = new Packages.java.lang.Integer(5)

Comment 1

[Dave]

-> OJI

Prolly a dupe?

Comment 2

[Chase Tingley]

should this really be in OJI rather than liveconnect?

Comment 3

[Dave]

Hm... didn't know there was a liveconnect component.

I'm thinking that this is a dupe of bug 64319 but I'm not sure so I'll let
someone else decide what to do with it.

Comment 4

[edburns]

Reassign to Joe as I'm leaving the role of OJI module owner.

Comment 5

[edburns]

Ressign to Joe Chou, as I am no longer working officially on OJI.

Comment 6

[Igor Nekrestyanov]

Reproducible on Linux (Redhat 6.2, jdk1.3.1)
But non-reproducible on solaris - i am getting 
  "Error reading file javascript: var x = new Packages.java.lang.Integer(5)"
to console.

Comment 7

[Igor Nekrestyanov]

Attachment: Top of gdb stacktrace for crash (on Linux)

Comment 8

[Igor Nekrestyanov]

Here is summary of my findings by now:

Testcase attempt to access java class which was 
not used before and therefore this class needs to be loaded.
Unfortunatelly liveconnect tries to use ProxyClassLoader
for this (through env->FindClass) 
which is also not loaded yet. In turn this trigger attempt to load
corresponding class through the same way and result in infinite recursion.

This is not just due to lazy loading because even if you 
visit pages with applets (and even pages with js code accessing applets),
open javascript console and try testcase then you will get same
problem.

My understanding is that liveconnect tries to use wrong classloader
(due to incorrect initialization?). However i am not sure 
what is the correct classloader (or JNIEnv?) and when (and how)
it is supposed to be updated.

Here is top of stacktrace just before the infinite recursion:
(The stacktrace with recursion itself is attached to the bug description.)

#0  ProxyFindClass (env=0x881fb80, name=0x881fb58 "java")
    at ProxyClassLoader.cpp:168
#1  0x418189ba in ProxyJNIEnv::FindClass (env=0x881fb80, name=0x881fb58
"java")
    at ProxyJNI.cpp:281
#2  0x4029c5c5 in JavaPackage_resolve (cx=0x878ec40, obj=0x872d2a0, 
    id=135240428) at jsj_JavaPackage.c:197
#3  0x400aede5 in _js_LookupProperty (cx=0x878ec40, obj=0x872d2a0, 
    id=135895248, objp=0xbfff9fe4, propp=0xbfff9fe0, 

This looks like design flow and i at the moment i do not 
what is the proper way to solve this. 
Any ideas how this supposed to work?

Comment 9

[Olivier Cahagne]

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

Comment 10

[Olivier Cahagne]

Reassigning to Live Connect component to check if this is the right component,
can the owner confirm ? Otherwise, change it back to OJI again.

Comment 11

[Olivier Cahagne]

Attachment: Reduced testcase (one line of JavaScript to Java) that crashes

Comment 12

[Phil Schwartau]

Attachment: Reduced testcase with alertboxes before/after var assignment

Comment 13

[Phil Schwartau]

If you try the testcase above, in NN4.7 you will see both alertboxes:
"Begin" and "End". They are coded before and after the var assignment

        var toolkit = Packages.java.awt.Toolkit.getDefaultToolkit();


In Mozilla, you will only see the first alertbox. The variable assignment
apparently causes a silent error in Mozilla (using binary 20011004xx WinNT).
There are no errors in the JavaScript Console. I am not crashing, however.


The same is true if I try this in HTML:

        var x = new Packages.java.lang.Integer(5);

Again, I do not get the second alertbox to come up, I do not get any errors
in the JavaScript Console, but I do not crash -

Comment 14

[Phil Schwartau]

In the standalone LiveConnect shell, all this works perfectly. 
I am able to declare the variables "x" and "toolkit" as above,
and get a return value. For example, 

js> typeof x
object

js> typeof toolkit
object


Therefore this belongs in OJI; reassigning back - 


NOTE: to build the standalone LiveConnect shell, check out 
mozilla/js/src/liveconnect, cd to this directory, and do:

            make -f Makefile.ref
            make -f Makefile.ref BUILD_OPT=1

to build the debug and optimized shells, respectively - 

Comment 15

[Phil Schwartau]

And changing Owner back to Joe, as it was previously -

Comment 16

[blakewilliams1]

If it worth anything,
It appears that using 
var val = new java.lang.Integer(5) works correctly, but
var val = new Packages.java.lang.Integer(5) causes a crash

name resolution with Packages seems to cause the crash

Comment 17

[Phil Schwartau]

[e-mail]: thank you!

I still don't crash on the testcases above, but now I AM getting
an error in the JavaScript Console:

     Error: Packages is not defined
     Source File: 
     http://bugzilla.mozilla.org/attachment.cgi?id=52448&action=view
     Line: 3

This shows why I never had any trouble above in the standalone 
LiveConnect shell: because Packages IS defined there:

[//d/JS_TRUNK/mozilla/js/src/liveconnect/WINNT4.0_DBG.OBJ] ./lcshell
js> typeof Packages
object

Comment 18

[Phil Schwartau]

cc'ing Patrick. One of these two bugs is a duplicate of the other:
this bug and bug 104134. Don't know which way to dupe, because I
don't know who is responsible for defining the Packages object in
the browser: the LiveConnect component or OJI? 

Comment 19

[Phil Schwartau]

My apologies - not all my Mozilla binaries have Java2 installed. 
That's why Packages was coming up undefined. 

When I have the Java2 plug-in installed, my trunk binaries dated
20011016xx on WinNT, Linux crash badly on both testcases above. 

Comment 20

[S. Malling]

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

Comment 21

[S. Malling]

regression from 0.9.2... kinda late i know, but i could help.

Comment 22

[Phil Schwartau]

Using Mozilla trunk binary 20011105xx on WinNT. Current status
is the same as reported by Blake in Comment 16:

javascript: var x = new java.lang.Integer(5);            ------>  OK
javascript: var x = new Packages.java.lang.Integer(5);   ------>  CRASH!!!


Note: the latter crash is not immediate; you get 100% CPU
for several seconds, and then the crash.

Comment 23

[Patrick C. Beard]

I saw this crash when the class |netscape.oji.ProxyClassLoaderFactory| was
missing from the class path. Evidently the code that uses it isn't being careful
enough when the class is not found. Please confirm whether or not this class is
in the JRE/Java plugin's classes.

Comment 24

[Patrick C. Beard]

I will diagnose this on Mac OS X by removing the class temporarily.

Comment 25

[Patrick C. Beard]

The crash is caused by an infinite recursion when ProxyFindClass() tries 
to look up the class |netscape.oji.ProxyClassLoaderFactory| and it isn't 
there, and the ProxyJNI turns around and calls ProxyFindClass() to get it. 
There was even a "TODO" comment in the code reminding to fix this. Well 
it's certainly time to fix this now. Working on a quick fix.

Comment 26

[Patrick C. Beard]

Attachment: Fix for infinite recursion in ProxyJNI.

This should fix the problem. Also added JDK1_2 compatibility methods, which
will prevent crashes when we migrate to a JDK 1.2 version of jni.h.

Comment 27

[Patrick C. Beard]

Patch fixes problem.

Comment 28

[Patrick C. Beard]

Duh, leaving bug open until fix checked in.

Comment 29

[Peter Lubczynski]

Comment on attachment 57232 [details] [diff] [review]
Fix for infinite recursion in ProxyJNI.

r=peterl looks good to me!

Comment 30

[Xiaobin Lu]

r=[e-mail]
The patch looks good to me also!

Comment 31

[Chris Waterson]

Comment on attachment 57232 [details] [diff] [review]
Fix for infinite recursion in ProxyJNI.

sr=waterson

Comment 32

[Patrick C. Beard]

Moving to 0.9.7, and planning to get this checked into the trunk today.

Comment 33

[Patrick C. Beard]

Fix checked into trunk.

Comment 34

[Patty Mac]

Follow the steps of how to reproduce from the reporter:

Reproducible: Always
Steps to Reproduce:
1. type javascript: in the URL window
2. In the js console, type:
var x = new Packages.java.lang.Integer(5).
On windows and linux, it works fine-no crash. 
However, on the Mac os 9.2, it crashes. 
Reopen bug.


Stack Trace
MRJPlugin + 0x113b4 (0x3cbb4624)
MRJPlugin + 0x15cd8 (0x3cbb8f48)
MRJPlugin + 0x11ab4 (0x3cbb4d24)
MRJPlugin + 0x13238 (0x3cbb64a8)
ProxyJNIEnv::FindClass() [ProxyJNI.cpp, line 279]
init_netscape_java_classes() [jsj.c, line 348]
jsj_ConnectToJavaVM() [jsj.c, line 500]
JSJ_AttachCurrentThreadToJava() [jsj.c, line 697]
map_js_context_to_jsj_thread_impl() [lcglue.cpp, line 209]
jsj_EnterJava() [jsj_utils.c, line 456]
JavaPackage_resolve() [jsj_JavaPackage.c, line 167]
js_LookupProperty() [jsobj.c, line 2215]
js_GetProperty() [jsobj.c, line 2374]
js_Interpret() [jsinterp.c, line 2623]
js_Execute() [jsinterp.c, line 1012

Comment 35

[Patrick C. Beard]

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

Comment 36

[Matthias Versen [:Matti]]

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

Comment 37

[William hodgert]

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

Comment 38

[Patrick C. Beard]

This is fixed.

Comment 39

[Patty Mac]

Verified on mac os 9.2 (2002-01-30-08-trunk)