Registering LiveConnect methods looks for non-existent constructor for JSObject

VERIFIED WORKSFORME

Status

Core Graveyard
Java: OJI
--
critical
VERIFIED WORKSFORME
16 years ago
8 years ago

People

(Reporter: Rob Heiser, Assigned: Patrick C. Beard)

Tracking

({crash})

Trunk
PowerPC
Mac OS X
crash

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1a+) Gecko/20020701
BuildID:    2002070103

In the file LiveConnectNativeMethods.cpp, line 122 (as of now), a JNI call has
previously been made to pick up the class netscape.javascript.JSObject, which
succeeds. Then an attempt is to get the method from that class with the
signature <init>(I)V -- a constructor that takes an int argument. Here is a
summary of the class, where no constructor that matches exists:

public abstract class netscape.javascript.JSObject extends java.lang.Object {
    protected netscape.javascript.JSObject();
    public abstract java.lang.Object call(java.lang.String, java.lang.Object[])
throws netscape.javascript.JSException;
    public abstract java.lang.Object eval(java.lang.String) throws
netscape.javascript.JSException;
    public abstract java.lang.Object getMember(java.lang.String) throws
netscape.javascript.JSException;
    public abstract void setMember(java.lang.String, java.lang.Object) throws
netscape.javascript.JSException;
    public abstract void removeMember(java.lang.String) throws
netscape.javascript.JSException;
    public abstract java.lang.Object getSlot(int) throws
netscape.javascript.JSException;
    public abstract void setSlot(int, java.lang.Object) throws
netscape.javascript.JSException;
    public static netscape.javascript.JSObject getWindow(java.applet.Applet)
throws netscape.javascript.JSException;
}

As a separate issue, I think each JNI call should be error checked in the chance
that an exception could be missed.


Reproducible: Always
Steps to Reproduce:
1. Run Mozilla build 2002070103
2. Open http://sodaplay.com


Actual Results:  Mozilla crashes

Expected Results:  A page with applets should open

Comment 1

16 years ago
LiveConnectNativeMethods.cpp is in the OJI module; reassigning -
Assignee: rogerl → joe.chou
Component: Live Connect → OJI
QA Contact: pschwartau → pmac

Updated

16 years ago

Comment 2

16 years ago
I can confirm that this does indeed cause a crash;  I've never tried Java -> JS
with Fizzilla before, so I'm wondering if this is a regression or just unknown?

Comment 3

16 years ago
Hmm.  Trying again with todays trunk build (2002070808) seems to get started OK
with LiveConnect, using my test case.  However, I get a hang later on.

I'll build a public testcase that can demonstrate this, which might be a good
"stress-test" for Java LiveConnect (on all platforms).  

Rob:  I won't question that you did the work in looking at the code, and maybe
something changed.  But make sure you have only one plugin in your path (newer
Mozilla comes with one in Mozilla.app/Contents/MacOS/Plug-ins).  I'm not sure if
something "bad" happens if you have that one, and also one in "/Library/Internet
Plug-Ins".  

Also, after crashing Mozilla once under a recent dev release of OSX, I got into
this state where, even if I logged out and logged back in, and then relaunched
Mozilla, it's windows wouldn't appear (although they'd show up in Mozilla's
"Window" meny, they did not appear on screen).  I don't know who or where to
report that one... 

Comment 4

16 years ago
Mac bug, re-assign to Patrick.
Assignee: joe.chou → beard

Comment 5

16 years ago
Hmmm even more.

OK, so although this seems to work with my complicated application, it doesn't
work for a simple test applet.  I'm smelling a race condition somewhere.

For a _very_ simple testcase that does _NOT_ WFM with 20020708, try
http://stevek.com/ForMozilla/LiveConnect/test.html

This page contains a textarea, and an applet, and the applet would (if it
loaded) use a simple javascript function to append stuff to the textarea.  But
on OSX, it doesn't even load.

It was _intended_ to be a reduced testcase for a different bug, which seems to
be that repeated, relatively rapid calls to JSObject.call() seem to result in
Mozilla locking up.  That still happens, (and maybe for people who win/lose this
race, it still will).  Maybe I'll write that up separately(?).

Anyways, this testcase ends up giving me "JSobj is null" in the Java Console
Log, while it does the right thing, more or less, on other platforms.

The source is all there also at http://stevek.com/ForMozilla/LiveConnect/

-SteveK

Comment 6

16 years ago
Both the URL and the testcase in comment #5 WorkForMe using
FizzillaCFM/2002062203. No crashes occurred.

Comment 7

16 years ago
OK, so I'm trying some more browsers.  All of these results are on 10.1.5, with 
MRJPluginCarbon in /Library/Internet Plug-Ins/:

Mozilla-0.9.9:  Fails: JSObj is null.
Mozilla-1.0 (2002052918): Fails: JSObj is null.
Mozilla-1.0+ (2002062705): Fails: JSObj is null.
Mozilla-1.1pre (2002070808): Fails: JSObj is null.

In every case, this is what I get in my Java Console.Log (except changing times):
=============
MRJ Plugin for Mac OS X v1.0
[starting up Java Applet Security @ Tue Jul 09 10:17:20 EDT 2002]
init() called
JSobj is null?!?
ouch.
start() called
run() called
JSobj is null?!?
exiting.
=============

So, why does this fail for me, but work for Greg?  I am able to run Java Applets on my 
machine (i.e. with my 1.1pre build, sodaplay.com works just fine).

I also tried this on a more "production" machine, with NS6.2 (MRJPlugin 1.0fc1), and it 
worked there.  

So, it still seems to me like some race condition somewhere (since LiveConnect works 
for me on this machine for more complicated test cases), but I'd love for someone else to 
see the failure to confirm this.

I also ran ASP on these two machines, both TiBook/500's, to see the software 
differences.  It seems they're running identical Java VMs, but different kernels (maybe 
from the networking update?):

I'll attach a diff of the ASP reports here.  (+ is the machine with the failures, - is the 
machine that succeeded).

Comment 8

16 years ago
Created attachment 90615 [details]
diff of ASP between two machines (+ fails testcase, - passes)

Comment 9

16 years ago
Retested Steve's test using FizzillaCFM/2002070913. The first attempt hung
Mozilla for some reason. Second attempt succeeded, but I noticed it generates a
lot of messages to the console (log to be attached), as does the original URL
reported on this bug.

Comment 10

16 years ago
Created attachment 90801 [details]
Messages sent to the Java console by FizzillaCFM/2002070913 running Steve's test

Updated

16 years ago
QA Contact: pmac → petersen

Comment 11

16 years ago
Rob, can you still reproduce this problem using a current nightly build?
(Reporter)

Comment 12

16 years ago
No, I can't reproduce it with build 20030213. Looks fixed to me.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 13

16 years ago
Should be resolved WFM.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---

Comment 14

16 years ago
Re-resolving.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 15

16 years ago
Rubber-stamp vrfy -
Status: RESOLVED → VERIFIED

Updated

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