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

VERIFIED FIXED in mozilla0.9.8

Status

defect
--
critical
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: javadesigner, Assigned: beard)

Tracking

({crash, testcase})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

18 years ago
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

18 years ago
-> OJI

Prolly a dupe?
Assignee: asa → edburns
Component: Browser-General → OJI
QA Contact: doronr → pmac

Comment 2

18 years ago
should this really be in OJI rather than liveconnect?
Severity: normal → critical
Keywords: crash, stackwanted

Comment 3

18 years ago
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

18 years ago
Reassign to Joe as I'm leaving the role of OJI module owner.
Status: UNCONFIRMED → NEW
Target Milestone: --- → mozilla0.9.5

Comment 5

18 years ago
Ressign to Joe Chou, as I am no longer working officially on OJI.
Assignee: edburns → joe.chou
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Comment 6

18 years ago
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 8

18 years ago
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

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

Comment 10

18 years ago
Reassigning to Live Connect component to check if this is the right component,
can the owner confirm ? Otherwise, change it back to OJI again.
Assignee: joe.chou → rogerl
Status: NEW → UNCONFIRMED
Component: OJI → Live Connect
QA Contact: pmac → pschwartau

Updated

18 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

18 years ago
Keywords: testcase

Comment 13

18 years ago
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

18 years ago
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 - 
Assignee: rogerl → edburns
Component: Live Connect → OJI
QA Contact: pschwartau → pmac

Comment 15

18 years ago
And changing Owner back to Joe, as it was previously -
Assignee: edburns → joe.chou

Comment 16

18 years ago
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

18 years ago
blakewilliams1@netscape.net: 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

18 years ago
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

18 years ago
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

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

Comment 21

18 years ago
regression from 0.9.2... kinda late i know, but i could help.
OS: Windows 2000 → All
Summary: Liveconnect crash on Moz 0.9.4 → Liveconnect crash on Moz 0.9.5

Comment 22

18 years ago
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.
(Assignee)

Comment 23

18 years ago
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.
Assignee: joe.chou → beard
(Assignee)

Comment 24

18 years ago
I will diagnose this on Mac OS X by removing the class temporarily.
(Assignee)

Comment 25

18 years ago
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.
Status: NEW → ASSIGNED
(Assignee)

Updated

18 years ago
Keywords: stackwanted
Summary: Liveconnect crash on Moz 0.9.5 → ProxyJNI Crashes when |netscape.oji.ProxyClassLoaderFactory| is missing
(Assignee)

Comment 26

18 years ago
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.
(Assignee)

Comment 27

18 years ago
Patch fixes problem.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 28

18 years ago
Duh, leaving bug open until fix checked in.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Updated

18 years ago
Keywords: review
(Assignee)

Updated

18 years ago
Status: REOPENED → ASSIGNED

Comment 29

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

r=peterl looks good to me!
Attachment #57232 - Flags: review+

Comment 30

18 years ago
r=Xiaobin.Lu@eng.Sun.com
The patch looks good to me also!

Comment 31

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

sr=waterson
Attachment #57232 - Flags: superreview+
(Assignee)

Comment 32

18 years ago
Moving to 0.9.7, and planning to get this checked into the trunk today.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
(Assignee)

Comment 33

18 years ago
Fix checked into trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 34

18 years ago
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 35

18 years ago
*** Bug 111039 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

18 years ago
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.7 → mozilla0.9.8
*** Bug 117686 has been marked as a duplicate of this bug. ***

Comment 37

18 years ago
*** Bug 113957 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 38

18 years ago
This is fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 39

18 years ago
Verified on mac os 9.2 (2002-01-30-08-trunk)
Status: RESOLVED → VERIFIED

Updated

9 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.