64319 - Java to JavaScript: pointer to the applet object is hard coded to NULL

Status: VERIFIED WORKSFORME

(Core Graveyard :: Java: OJI, enhancement, P3)

Description

[katt]

LiveConnect: Java to JavaScript: 
The pointer to the applet object is hard coded to NULL in the SetMember
funcion in nsCLiveConnect.cpp.

A request of JAVA_PLUGIN_JNIJS_SETMEMBER is generated by an applet.
(example:http://www.apl.jhu.edu/~hall/CWP-Sources/CWP-Examples/Chapter1
9/Everest.html -- clicking on the "cost slider")

Upon receiving this, remotejni.cpp makes a call to the SetMember 
function in nsCLiveconnect.cpp.  The SetMember function then makes a 
call to the jsj_enter_js function in jsj_JSObject.c passing in a 
hardcoded NULL for the second parameter (a pointer to the applet 
object).  

The jsj_enter_js method then makes a call to the 
map_jsj_thread_to_js_context_impl method of lcglue.cpp passing in the 
applet object pointer (which is the hardcoded NULL from the SetMember 
method) as the second parameter.  

The map_jsj_thread_to_js_context_impl method checks if this parameter 
is NULL and if so returns NULL for the JSContext.  

This causes the failure to occur (the web page entry field is not 
updated).  While debugging, if this null value is manually changed, so 
it actually points to the applet object, the applet is updated 
correctly.  

For applets to use LiveConnect Java to JavaScript, the parameter 
passed to jsj_enter_js needs to be a valid value.

Comment 1

[katt]

I should have mentioned that I am using the OS/2 version of Mozilla 
though it seems as though this would cause a problem on other platforms
as well.

Comment 2

[Phil Schwartau]

Not sure who owns this - reassigning to Patrick for further triage, 
as CVS associates him with the line mentioned above: 


  "The SetMember function then makes a call to the jsj_enter_js function 
   in jsj_JSObject.c ..." 



Reference:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/liveconnect/nsCLiveco
nnect.cpp#285

Comment 3

[katt]

This has also been attempted on Linux with the latest Sun FCS plugin 
and it failed here as well.  
On Windows with Netscape 6 and Sun FCS Plugin it seems to work fine.

Comment 4

[Patrick C. Beard]

There's no applet being passed to nsCLiveconnect::SetMember(), so there's nothing 

but NULL to pass to jsj_enter_js(). Clearly, the pNSISecurityContext parameter is 

needed to establish the appropriate security context. Adding Mitch to cc list.

Comment 5

[Thomas Lendacky]

I was able to debug this further...

It turns out that the first SetMember call works properly, it is subsequent 
calls that do not.  The reason for this is as follows:

Keeping in mind that the initial GetWindow call resulted in the JSContext value 
being put into the JSJavaThreadState structure (->cx) because the applet object 
was supplied on the call to GetWindow.

The Java object performs a (the first) SetMember call against a JSObject 
(JAVA_PLUGIN_JNIJS_SETMEMBER).
remotejni.cpp -> nsCLiveconnect::SetMember
	-> jsj_enter_js
	-> jsj_MapJavaThreadToJSJavaThreadState
This returns the JSJavaThreadState structure which has ->cx set to a valid 
JSContext.  When ->cx is checked and found to not be null we continue and
return the JSJavaThreadState structure to SetMember.  SetMember then
	-> jsj_ConvertJavaObjectToJSValue
	-> jsj_WrapJavaObject
	-> JS_NewObject
	-> js_NewObject
	-> JavaObject_getPropertyById
	-> jsj_EnterJava
In jsj_EnterJava the JSJavaThreadState structure ->recursion_depth is 
incremented (from 0 -> 1) and ->cx is set (to the same value).  Upon completion, 
JavaObject_getPropertyById
	-> jsj_ExitJava
In jsj_ExitJava the JSJavaThreadState structure ->recursion_depth is decremented 
(from 1 -> 0) and since ->recursion_depth == 0 then ->cx  is set to null.  This 
has no ill effect to the remainder of this SetMember call.

The Java object performs a (the second) SetMember call against a JSObject 
(JAVA_PLUGIN_JNIJS_SETMEMBER).
remotejni.cpp -> nsCLiveconnect::SetMember
	-> jsj_enter_js
	-> jsj_MapJavaThreadToJSJavaThreadState
This returns the JSJavaThreadState structure which now has ->cx set to null.  
When ->cx is checked and found to be null
	-> map_jsj_thread_to_js_context_impl
Since SetMember is called without a pointer to an applet object, 
map_jsj_thread_to_js_context_impl returns a null JSContext which causes a null 
JSJavaThreadState to be returned to SetMember which then fails.

Comment 6

[Thomas Lendacky]

I've made a change that appears to work.  I've attached the diffs for modules 
mozilla/js/src/liveconnect/jsj.c, jsj_private.h, jsj_utils.c.  Basically the fix 
is to save the current value JSJavaThreadState value of "cx" into "cx_previous" 
if the "recursion_depth" is going to be incremented from 0 and to restore the 
value of "cx" from "cx_previous" if the "recursion_depth" is going to be 
decremented to 0.

Please look over and see if these changes are acceptable.

Comment 7

[Thomas Lendacky]

Attachment: Diffs of jsj.c, jsj_private.h, jsh_utils.c

Comment 8

[Mitchell Stoltz (not reading bugmail)]

Hi Mitch -
The patch seems to be safe enough. When I get a chance, I will run it
through the debugger. I have a general concern that bugs in the way
JSContexts and Java threads are mapped is the source of several
significant Liveconnect problems. This may fix just one of those
problems. What is needed is for someone to study the interaction between
LC,OJI (as in lcglue.cpp), and JNI to get a good understanding of what
is really going on. But I digress...
I give it a 'visual' thumbs up.
-jd

I think we can consider that an r=jeff
  -Mitch

Comment 9

[Thomas Lendacky]

Mitch, I don't have checkin capability...  could you do the honors?

Comment 10

[Patrick C. Beard]

Unfortunately, the MRJ OJI plugin multiplexes multiple Java thread calls into 
JSObject methods on to the main browser thread. Therefore, it isn't strictly 
correct to leave a JSContext sticking to the JSJavaThreadState structure 
associated with the main Java thread. Instead, we need a way to cleanly 
associate, and disassociate multiple JSContexts with a common JNIEnv.

It occurs to me that we should count all transitions between JS and Java, but we 
currently only count transitions from JS to Java, not Java to JS. Thus, if a Java 
thread calls into JS, that should increment the recursion_depth, otherwise, if 
the call from Java to JS results in a call back to Java from JS, when Java 
returns to JS, jsj_ExitJava will incorrectly disassociate the JSContext from the 
JSJavaThreadState.

A brute force, but incompatible API change would be to alter the nsILiveconnect 
interface to require a pointer to the plugin instance in all of the API calls. 
This would always be used to associate the proper JSContext with each and every 
call from Java into JS. I'm not sure why this wasn't done in the first place. The 
MRJ plugin can do this, because it is able to recover the plugin instance by 
comparing the class loader of the currently running Java method with the class 
loader of each running applet.

Comment 11

[Xiaobin Lu]

Patrick:
   Could we add another interface nsILiveconnect2 which can achieve what you 
mentioned in the last comment? Would you like to post a patch for this bug?
    Thanks very much!

Comment 12

[Xiaobin Lu]

  With Beard's patch for bug 63466,it works now.
  Thanks!

Comment 13

[Phil Schwartau]

Patrick: based on Xiaobin's comment above, may we mark this bug as "Fixed"?
Or is there more you want to do on this one? 

Comment 14

[Patrick C. Beard]

Sure, as long as we can verify this test case, I'd say this is fixed.

Comment 15

[Phil Schwartau]

Sorry, I don't see a testcase here, and I'm out of my depth on this one. 
I will mark this bug FIXED, but can someone who has a testcase verify this? 
If everything is OK now, please mark the bug VERIFIED; otherwise, reopen it.

Thanks - 

Comment 16

[Xiaobin Lu]

  I am here to provide a test case, please open the attchment for my testcase.

Comment 17

[Xiaobin Lu]

Attachment: A testcase: Java call Javascript using setMember

Comment 18

[Phil Schwartau]

My apologies, now I see the original testcase - in the URL field  - sorry!


We've made progress: Mozilla-2001-02-09-xx WinNT couldn't even load 
the URL, and gave me this error in the Java Console:

Java(TM) Plug-in: Version 1.3.0_01
Using JRE version 1.3.0_01 Java HotSpot(TM) Client VM
Proxy Configuration: Browser Proxy Configuration

----------------------------------------------------
java.lang.NullPointerException
	at Everest.init(Everest.java:48)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)



Now, Mozilla-2001-02-13-15 WinNT loads the URL without any problem; no errors 
in the Java Console. And you can slide the slider bar at the bottom of the 
Everest applet. BUT -  after sliding it around for awhile, if you hit "Reload" 
on the browser, you crash: 



WINNT STACK TRACE

JPINS32! 502e5ac1()
enter_js_from_java_impl(JNIEnv_ * 0x022c5f70, char * * 0x0012fafc, void * * 
0x00000000, int 0, void * 0x009659f0, void * 0x0286f358) line 419 + 19 bytes
jsj_enter_js(const JNINativeInterface_ * * 0x022c5f70, void * 0x0286f358, 
_jobject * 0x00000000, JSContext * * 0x0012fb48, JSObject * * 0x00000000, void 
(JSContext *, const char *, JSErrorReport *)* * 0x0012fb40, void * * 0x00000000, 
int 0, void * 0x009659f0) line 705 + 33 bytes
nsCLiveconnect::SetMember(nsCLiveconnect * const 0x11ec00e0, JNIEnv_ * 
0x022c5f70, long 294930832, const unsigned short * 0x00965c80, long 5, _jobject 
* 0x0095bcf0, void * * 0x00000000, int 0, nsISupports * 0x009659f0) line 285 + 
40 bytes
JPINS32! 502ea89b()
JPINS32! 502ea56a()
PL_HandleEvent(PLEvent * 0x11edc4c0) line 576 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00ac48c0) line 509 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x05c404b4, unsigned int 49340, unsigned int 0, 
long 11290816) line 1054 + 9 bytes
USER32! 77e71820()
00ac48c0()



ONE FRAME BELOW CRASHPOINT: here is where the Visual C++ debugger was pointing:

static JSBool PR_CALLBACK
enter_js_from_java_impl(JNIEnv *jEnv, char **errp,
                        void **pNSIPrincipaArray, int numPrincipals, 
                        void *pNSISecurityContext,
                        void *java_applet_obj)
{
	JVMContext* context = GetJVMContext();

    // Get and Save the current applet object in the vm context.
    // There is not a 1:1 coorespondence between jvmcontexts and
    // jscontexts, but there is a 1:1 correspondence between
    // jvmcontexts and applet objects. So syncronize the two
    // here and use the applet object to get the jscontext when
    // needed.

    if (java_applet_obj) {
        context->java_applet_obj = java_applet_obj;
    }
    else if (context->java_applet_obj) {
        java_applet_obj=context->java_applet_obj;
    }

    JSContext *pJSCX    = 
map_jsj_thread_to_js_context_impl(nsnull,java_applet_obj,jEnv,errp); <<<<<<HERE 
    nsCOMPtr<nsIPrincipal> principal;

    if (pNSISecurityContext != nsnull) {

                    ETC.
                    ETC.




On Linux, Mozilla 2001-02-13-08 crashes when attempting to load the given URL. I 
see this error in the Mozilla debug console: 

#
# HotSpot Virtual Machine Error, Unexpected Signal 11
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Error ID: 4F533F4C494E55580E43505005BC
#
# Problematic Thread: prio=1 tid=0x8421d00 nid=0x40c6 runnable 
#
INTERNAL ERROR on Browser End: Pipe closed during read? State may be corrupt
System error?:: Success


As a result of these issues, reopening bug - 

Comment 19

[Xiaobin Lu]

  Is this a duplicate of bug 66324?

Comment 20

[Xiaobin Lu]

  The reason that it crashes seems like when it call 
map_jsj_thread_to_js_context_impl, during this call it calls pluginInstance-
>GetPeer(&pluginPeer), which causes an error because the peer member of 
pluginInstance(i.e. java_applet_obj)is NULL, so when it calls mPeer->AddRef(), 
it causes crash.
   I think that the initialization of java_applet_obj has some problem, at 
least it is not complete. 

Comment 21

[Xiaobin Lu]

  The reason seems clear: When we hit the reload button, the java plugin is 
destroyed (CjavaPlugin:destroy is called)and the peer of the plugin instance is 
set to null. 
  This is why the next step when we call pluginInstance->GetPeer (&pluginPeer), 
it gets the browser crash! So,do we really need to call CJavaPlugin:Destroy 
even we hit the reload button?

Comment 22

[edburns]

Yes we do, Stanley requested this behavior.

Comment 23

[Xiaobin Lu]

During the call to get the JSContext, it actually ask the applet object to get 
a pluginInstancePeer. The code looks like: 

if (pluginInstance->GetPeer(&pluginPeer) == NS_OK) {
			nsIPluginInstancePeer2* pluginPeer2 = NULL;
			if (pluginPeer->QueryInterface(NS_GET_IID
(nsIPluginInstancePeer2), (void**) &pluginPeer2) == NS_OK) {
				pluginPeer2->GetJSContext(&context);
				NS_RELEASE(pluginPeer2);
			}

How about if the pluginInstance peer is null as the case here?
We need an alternative method to get the JSContext, does that make sense?

Comment 24

[Patrick C. Beard]

Evidently we're being bit by a dangling pointer to the plugin instance this is 
being referenced in the mJavaClient field introduced in the fix for bug #63466. 
The Java plugin really needs to be fixed to stop using the nsILiveconnect 
instance as a singleton, but on a 1 per plugin instance basis. 

Comment 25

[Xiaobin Lu]

Attachment: The patch to avoid crash

Comment 26

[Xiaobin Lu]

The reason of this crash is pluginInstance was destroyed when hitting reload. 
However, the browser is still trying to call "map_jsj_thread_to_js_context_impl" 
to get a JSContext from the pluginInstance which is not valid. So as we know the 
map_jsj_thread_to_js_context_impl is called often, so it is better to cache the 
JSContext and applet object mapping somewhere in a list, so next time, just 
returns the JSContext with the correct appletObject. Also, when the applet 
object is gone, we are still safe to use that JSContext 
temporary(normally during jsj_ExitJava) instead of asking an invalid 
pluginInstance for the JSContext. I don't know this is the right thing to do. 
Patrick, can you let me know how do you think about this? 

Comment 27

[Patrick C. Beard]

I think the real fix is to stop using nsILiveconnect as a singleton, but on a per 
applet instance basis. I don't think your workaround is appropriate at this time.

Comment 28

[Xiaobin Lu]

Patrick:
   I think even the sigleton problem is fixed, we still have this kind of bug 
because when we reload the page, the pluginInstance is going to be destroyed 
anyway and at that time, any trys to use the pluginInstance ( such as to use it 
to get JSContext) will be considered troublsome.
   My workaround just caches the JSContext with the corresponding applet object 
somewhere in order not to computer it next time. Also, even the plugin object is 
gone, we still have that JSContext cached. Maybe this is not a clean way to do 
this because the list still caches those applet object which got destroyed. 
However, this is pretty important to avoid crash. Also, this workaround is 
necessary to let patch 74482 checked in.

Comment 29

[Patrick C. Beard]

Your patch keeps an ever growing linked list of associations between plugin 
instances ("applets") and JSContexts. The list leaks indefinitely, and runs the 
risk of keeping dangling references to non-existent JSContexts. We need to fix 
this problem at the source, not with a workaround like this.

Comment 30

[Xiaobin Lu]

Reassign!

Comment 31

[Xiaobin Lu]

  After Investigating the code, I have found this bug should be marked as
"WONTFIX". What the bug means here is when you hit the reload or back button,
the browser got crash. The reason is when you pull the slide bar, the java code
will invoke the javascript call SetMember for every position the bar arrives, so
before the slide bar got stable, when this time you hit the reload button, the
browser of course will get crash because the reason I mentioned before. Plus the
current java plugin side implementation didn't follow the standard design rule (
they should use nsCOMPtr to ensure the pluginInstance will be released at
appropriate time). So I don't think the bug will be fixed considering not many
people use the testcase that crazy(before the slide bar get stable, hit reload
button).

Comment 32

[Phil Schwartau]

Any comments from anyone?  Has the original issue of this bug been resolved 
to everyone's satisfaction?

cc'ing Patrick -

Comment 33

[edburns]

Is this really WONTFIX?  If so, mark it as such.  For the record, using the 
attached testcase on Win32 works fine on Wednesday's trunk.

Comment 34

[drapeau]

I'm not really following the line of thought on this bug.  I'm seeing comments
that suggest fixing the root cause (java plugins should stop using
nsILiveConnect as a singleton); if that's the agreed upon cause of action, then
this bug should be marked as a dependency on that one (don't recall the bug
number).  Later, I see comments saying this is WONTFIX because it's an uncommon
case?  That's not a good reason in my book.

Finally, I infer from the last few comments that it is the responsibility of the
Java Plug-In to do the right thing, but it is not.  If that's the case, then I
recommend you close the bug as INVALID, along with written justification stating
what the browser expects a Java plugin to do, and why you believe the Java
Plug-In is in error.  If this is not a Mozilla bug, that's the correct course of
action.

Comment 35

[Xiaobin Lu]

Some investigation result about this bug:
  * The reason of this bug is when the user hit the reload button, the 
nsObjectFrame associated with the applet plugin instance got destroyed so that 
the applet object got destroyed by plugin side. However, if there is any still 
pending events in the event queue such as nsCLiveconnect:SetMember, the browser 
will still try to execute these old events. If all these events are processed 
after nsCLiveconnect:GetWindow is processed, everything will be OK because the 
applet object is a fresh one. Of course, that's impossible and this is why we 
see the crash when the liveconnect code tries to get JSContext via the old 
INVALID applet object instance. 

Solution to this mess:
    * If the XPCOM event processor can be smart enough to know that after reload 
button is pressed, no old events should be processed, that will be nice. Is that 
possible? Patrick, can you comment on this possibility?
    * We can make a java plugin map to store the alive applet object ( actually 
JPI use this way to track the alive applet object). Also store the JSContext 
associated with the applet object. This way, we can save time to get JSContext 
instead of asking pluginPeer everytime (this will improve the performance 
definetely). A very clean way needed to manange this list.

By the way, I worked with Stanley(JPI developer) and found that plugin side can 
not really do anything to avoid this crash because it makes little sense to 
store an invalid pluginInstance which maybe dangling (because liveconnect won't 
know when should destroy applet object).  

Comment 36

[Xiaobin Lu]

av:
    I would like to add an new interface to Plugin modules which has similar 
function as nsActivePluginList. Because I think it is easy for OJI module to 
keep track the alive applet plugin instance. Do you think is that OK?
    Thank you in advance!

Comment 37

[av (gone)]

Can you post a proposed header for this interface?

Comment 38

[Xiaobin Lu]

Thank you very much! I will do it after I discuss with Java plugin group.

Comment 39

[Xiaobin Lu]

A JPI architecture problem after 63466 fixed, something similar should be done 
to adapt the 63466's fix in JPI side.

Comment 40

[Xiaobin Lu]

The reload problem (actually reload the applet make the browser crash) actually 
is caused by the side effect of bug fix for 63466. In that bug, the fix actually 
makes an association between nsCLiveConnect instance with Java applet object. 
This is OK for most of times. However, the problem is nsCLiveConnect 
implementation does not track that the applet object is gone or not. Also the 
Java plugin side needs to do corresponding change to this association descibed 
above. So, there are two problems we need to consider to resolve:
1. Make a seperate nsCLiveConnect instance with the specific applet object. The 
plugin side may get the nsCLiveConnect instance by passing the applet plugin 
object.
2. Make nsCLiveConnect instance aware that the applet object is gone before 
dispatch. The case will become more complicated when the nsCLiveConnect call is 
running.

Comment 41

[Xiaobin Lu]

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

Comment 42

[Jacek Piskozub]

Upgrading the bug ( -> critical, ->crash) and nominating for mozilla0.9.5 as it
is contains a crash (per dup bug 89649 and Xiaobin's 7/17 comment)

Comment 43

[Xiaobin Lu]

A Sun intenal bugtraq bug filed against this bug. The bug ID is 4520400.

Comment 44

[Joe Chou]

Add Jay to CC list.

Comment 45

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 46

[Xiaobin Lu]

I would like to put this bug as an ehancement instead of a critical bug since 
this needs a lot of change in Java Plugin and OJI.

Comment 47

[Phil Schwartau]

> I would like to put this bug as an ehancement instead of a critical
> bug since this needs a lot of change in Java Plugin and OJI.

Setting component and QA to OJI; this is not an issue for the
LiveConnect component per se, which is the purely abstract API
between Java and JavaScript.

Comment 48

[Doron Rosenberg (IBM)]

Has any headway been made with this? 

Comment 49

[Rob Jaworski]

add me, my blocker, and Priority to P1.

Comment 50

[Xiaobin Lu]

This is a browser problem since the browser does not AddRefs correctly to
JSContext . It always relies on Applet object to find out JSContext. However,
the applet may gone when the user switch the page, This will lead to access
violation. So Reassign to OJI since they are thinking to redesign the
liveconnect code.

Comment 51

[Joe Chou]

I tried the original test case (load URL in the URL field) with moz1.0 /Netscape
pr1 and JRE 1.4.0_01, on Solaris, Linux and Windows XP. Loading the applet,
sliding the numeric bar, and reloading seemed working OK (on Linux, reload
sometimes causing crash though). 

Reporter and people interested, can you try with JRE 1.4.0_01? On Windows, just
copy NPxxx.dll to "plugins". On Unix (Solaris or Linux), make a symlink from
"plugins" to where libjavaplugin_oji.so is. It should be something like:
".../j2re1.4.0_01/plugin/sparc/ns600/libjavaplugin_oji.so". 

Comment 52

[Joe Chou]

Humm, no response. 
Pat, could you give it a try, and see if you see what I saw?

Comment 53

[Patty Mac]

Windows 2000:
Joe, I tried on windows 2000, Jre 1.4.0_01 (branch build: 2002-06-11-08-1.0.0),
I tried the orginal test case (load URL in the URL field) which is:
http://www.apl.jhu.edu/~hall/CWP-Sources/CWP-Examples/Chapter19/Everest.html
it loaded fine, even clicked on the reload button several time, it still loaded
fine.

Linux redhat 7.3:
I tried on linux redhat 7.3, Jre 1.3.1_02 (branch build: 2002-06-10-07-1.0.0),
the applets not loaded, generated the error. I even clicked on the reload button 
several time, it didn't crash at all. Will attach the error messages.

Mac os 9.2.2:
I tried on Mac os 9.2.2, choose Custom install (branch build: 
2002-06-13-05-1.0.0), the applets not loaded, generates the error. I even 
clicked on the reload button several time, it didn't crash at all. Will attach 
the error messages.

Mac os 10.1.5
I tried on Mac os 10.1.5, MRJ v.1.0 (branch build: 2002-06-13-05-1.0.0), the
applets not loaded, genertes the error. I even clicked on the reload button 
several time, it didn't crash at all. Will attach the error messages.

Comment 54

[WD]

Win2k JRE 1.4.0_01  2002061408
2 Talkbacks on the URL for this bug:
1) Clicking "Back" to go to the page with Java:
TB7345089H

2) Clicking the "Show Treks" button:
TB7345191W

Comment 55

[Patty Mac]

Sorry for the confusion, please ignore my comment #53 please.

Windows 2000:
I tried on windows 2000, Jre 1.4.0_01 (branch build: 2002-06-11-08-1.0.0),
I tried the orginal test case (load URL in the URL field) which is:
http://www.apl.jhu.edu/~hall/CWP-Sources/CWP-Examples/Chapter19/Everest.html
it loaded fine, even clicked on the reload button for several time, it still 
loaded fine.

Mac os 9.2.2:
I tried on Mac os 9.2.2, choose Custom install (branch build: 
2002-06-13-05-1.0.0), the applets loaded fine, even clicked on the reload 
button for several time, it still loaded fine.

Linux redhat 7.3:
I tried on linux redhat 7.3, Jre 1.3.1_02 (branch build: 2002-06-10-07-1.0.0),
the applets loaded fine just like windows 2K, but generated the errors in the 
java console window. I even clicked on the reload button for several time, it 
didn't crash at all. Will attach the error messages.

Mac os 10.1.5
I tried on Mac os 10.1.5, MRJ v.1.0 (branch build: 2002-06-13-05-1.0.0), the
applets not loaded, generated the errors in the java console window. I even 
clicked on the reload button for several time, it didn't crash at all. Will 
attach the error messages.

Comment 56

[Patty Mac]

Attachment: Errors occurs in linux redhat 7.3

Comment 57

[Patty Mac]

Attachment: Errors occur on Mac os 10.1.5, MRJ v1.0

Comment 58

[Patty Mac]

WD, I just tried again on windows 2000, choose custom install, jre 1.4.0_01
"today's branch build (2002-06-14-08-1.0.0)", with the orginal test case (load
URL in the URL field) which is:
http://www.apl.jhu.edu/~hall/CWP-Sources/CWP-Examples/Chapter19/Everest.html
it loaded fine. I even clicked on the reload button for several time, it still 
loaded fine, but it a bit slower than the one that I just commented in #55
(branch build: 2002-06-11-08-1.0.0).

Comment 59

[Phil Schwartau]

Here are those Talkback stack traces from Comment #54:

Incident ID 7345089
Product ID MozillaTrunk
Build ID 2002061408
Trigger Time 2002-06-14 12:05:40
Platform Win32
Operating System Windows NT 5.0 build 2195
Module
URL visited 
http://www.apl.jhu.edu/~hall/CWP-Sources/CWP-Examples/Chapter19/Everest.html
User Comments Java-related crash
Trigger Reason Access violation
Source File Name
Trigger Line No.
Stack Trace
0x00000006
map_jsj_thread_to_js_context_impl [lcglue.cpp, line 157]
enter_js_from_java_impl [lcglue.cpp, line 430]
jsj_enter_js [jsj_JSObject.c, line 713]
nsCLiveconnect::SetMember [nsCLiveconnect.cpp, line 286]
jpins32.dll + 0x9fb8 (0x01e99fb8)
jpins32.dll + 0x9b78 (0x01e99b78)
SETUPAPI.DLL + 0x30c24 (0x778b0c24) 


Incident ID 7345191
Product ID MozillaTrunk
Build ID 2002061408
Trigger Time 2002-06-14 12:07:33
Platform Win32
Operating System Windows NT 5.0 build 2195
Module
URL visited 
http://www.apl.jhu.edu/~hall/CWP-Sources/CWP-Examples/Chapter19/Everest.html
User Comments
Trigger Reason Access violation
Source File Name
Trigger Line No.
Stack Trace
0x0033005a
enter_js_from_java_impl [lcglue.cpp, line 430]
jsj_enter_js [jsj_JSObject.c, line 713]
nsCLiveconnect::SetMember [nsCLiveconnect.cpp, line 286]
jpins32.dll + 0x9fb8 (0x020a9fb8)
jpins32.dll + 0x9b78 (0x020a9b78)
SETUPAPI.DLL + 0x30c24 (0x778b0c24) 

Comment 60

[Joe Chou]

Pat, could you try on Linux using ns7.0 pr1 (available from netscape.com) and
JRE 1.4.0_01 (available from java.sun.com/j2se)? See what happens?

WD (of comment #54), what mozilla/netscape build did you use? Did you use ns7.0
pr1? How did you set up JRE 1.4.0_01?

Comment 61

[WD]

Joe:

I have tried Mozilla 2002061408 (1.1a trunk) and also the equivalent branch
(1.0.0) build
I installed JRE 1.4.0_01 Engligh-only Windows Installer from the sun website
I copied the npoji610.dll file to my plugins directory and explicitly set the
JRE path in the windows control panel applet for JRE 1.4.0_01

Steps to reproduce crash:
1) Move slider on the java applet
2) Press the Show Treks button

Crashes virtually every time.  Both on my work PC and home PC.  (Both Win2k,
1.4.0_01, latest moz build)

I have not tried Netscape.

Comment 62

[Phil Schwartau]

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

Comment 63

[Phil Schwartau]

From the duplicate bug 142756. Note the stack trace is the same as
the second one given in Comment #59 above:

When executing the applet below, the browser crashes (nightly builds hang
rather than crashing) after some number of LiveConnect calls to get 
JavaScript properties. The number of calls required for the browser to crash 
varies according to the property. For instance, window.defaultStatus does not 
cause a crash whereas window.closed typically causes a crash in less than 100 
repetitions.

The bug occurs when using either Sun JVM 1.3 or 1.4. Other JVMs
have not been tested.

Here is the applet:

import java.applet.*;
import java.awt.*;
import netscape.javascript.*;

public class LinuxBug extends Applet {
    Label midd = null;
    public void init() {
        setLayout(new GridLayout(1,1));
        midd = new Label("tmp");
        add(midd);
        setVisible(true);
    }

    public void start() {
        long i=0;
        while (1==1) {
            try {
                JSObject.getWindow(this).getMember(getParameter("whichprop"));
                if ((i++ % 10)==0) midd.setText(i + " " + 
getParameter("whichprop"));
            } catch (Exception e) {
                midd.setText("failure: " + getParameter("whichprop") + " " + 
e.toString());
                return;
            }
        }
    }
}


The following html invokes this applet:
<applet height=100 width=300 code="LinuxBug" MAYSCRIPT>
<param name="whichprop" value="closed">
</applet>


Reproducible: Always
Steps to Reproduce:
1. Load http://63.148.42.5/geoff/n6bug/linuxbug.html
2. Wait for browser to hang or crash.

Actual Results:  In the applet within the loaded page is the name of the
propery being accessed and a counter. After some time, the counter either
stops incrementing (and the entire browser hangs) or the browser crashes.

Expected Results:  The counter increments indefinitely

This bug does not occur under Windows.

This bug may be related to bug 112434 but I cannot tell.


------- Additional Comment_ #1 From Olivier Cahagne 2002-05-07 06:36 ------- 
Confirming using build 2002050604 on Win2k (trunk) + JRE 1.4.0.
I loaded URL above (param 'closed'), waited for 2.000 loops, closed window ->
Mozilla crashed (dunno if it's related but it's 100% reproducible on my box),
Talkback ID: TB6022758M.


------- Additional Comment_ #2 From Doron Rosenberg 2002-05-07 08:36 ------- 
Stack Signature  0x02d27f0c a69b2735
Email Address [e-mail]
Product ID MozillaTrunk
Build ID 2002050604
Trigger Time 2002-05-07 06:24:20
Platform Win32
Operating System Windows NT 5.0 build 2195
Module
URL visited
User Comments bug 142756
Trigger Reason Access violation
Source File Name
Trigger Line No.
Stack Trace
0x02d27f0c
enter_js_from_java_impl [lcglue.cpp, line 430]
jsj_enter_js [jsj_JSObject.c, line 713]
nsCLiveconnect::GetMember [nsCLiveconnect.cpp, line 182]
jpins32.dll + 0x9f3e (0x01ce9f3e)
jpins32.dll + 0x9b78 (0x01ce9b78)
SETUPAPI.DLL + 0x30c24 (0x778b0c24)

Comment 64

[Patty Mac]

I could produce this crash on windows 2000 (branch build: 2002-06-17-08-1.0.0)

1) Click on this url: 
http://www.apl.jhu.edu/~hall/CWP-Sources/CWP-Examples/Chapter19/Everest.html
2) Move the slider
3) Click the "Get Treks" button
4) Click the back button from the "Page not found" error returned
5) Repeat serveral time in order to see the crash.

Comment 65

[Patty Mac]

Here is the stacktrace:

0x03439c55 
enter_js_from_java_impl [d:\builds\seamonkey\mozilla\modules\oji\src\lcglue.cpp, 
line 430] 
0xf82680

Comment 66

[Patty Mac]

It also *hangs* on mac os 9.2.2 (branch build: 2002-06-17-05-1.0.0)
using the same procedure of how to reproduce on comment #64

Comment 67

[Steffen Meschkat]

Bug #89649, which was resolved as duplicate of this bug, seems fixed in Mozilla 
1.0.

Comment 68

[Joe Chou]

This bug has a long history, and the problem seems still happening on Windows
and Linux (worked on Solaris though). The cause of the problem seems due to some
defacts of the current interface of the browser and Java, and need to wait for
the redesign of the OJI module in the near future (as also suggested by
Xiaobin). That  is why the target of this bug right now is "future".

Comment 69

[Joe Chou]

Since the problem is a limited case, instead of a generic crash, lowering the
priority to 3 from 1. The problem will be addressed in the upcoming OJI re-design.

Comment 70

[Joshua Xia]

reassign to me

Comment 71

[dsirnapalli]

-- Verified in the latest trunk build on Win2K with JRE1.4.1_02. The above
mentioned test cases donot crash. Marking WORKSFORME. Bug owner, if you still
see the problem with latest JRE please reopen the bug.

Comment 72

[Michael Prentice]

Crashed on RedHat Linux 7.2, Mozilla 1.4a, 1.4.2 b19 JVM, Talkback ID TB19837706G.

Comment 73

[Phil Schwartau]

Reopening based on Mike's findings; will attach Talkback trace below -

Comment 74

[Phil Schwartau]

Attachment: Stack trace from Talkback ID TB19837706G

Comment 75

[Michael Prentice]

Also crashed on Solaris 8 and HP-UX 11.11.

[1]+  Exit 11                 ./mozilla

[2]+  Exit 4                  /usr/local/bin/netscape-v7.0


Mozilla 1.4a
Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.4a) Gecko/20030402
Java(TM) Plug-in 1.4.1.01

Mozilla 1.2.1 Beta for Solaris
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1) Gecko/20030313
Java(TM) Plug-in 1.4.2-beta-b19

Netscape 7.0
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 
Java(TM) Plug-in 1.4.1-b21

Comment 76

[Michael Prentice]

I tested this today on Redhat 7.2, Mozilla 1.4a, and the 1.5.0 JRE and
reproduced the crash.

Talkback ID: TB20023933K

Linux qwin145 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown

java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b06)
Java HotSpot(TM) Client VM (build 1.5.0-beta-b06, mixed mode)

Comment 77

[Phil Schwartau]

Attachment: Stack trace from Talkback ID TB20023933K

Comment 78

[Xiaobin Lu]

The ultimate cause of this bug is Mozilla uses a dead pluginInstance pointer 
to get peer and then get JSContext. I think the one of the thing missing from 
the current OJI interface is the notification of destroy of applet. 

Comment 79

[Joshua Xia]

->kyle

Comment 80

[Kyle Yuan]

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

Comment 81

[Bernard Alleysson]

I have no crash on Windows here, unlike with bug 222237
Here there is a NULL pointer dereference but not in bug 222237 but
I agree that the stack looks the same.

Comment 82

[Kyle Yuan]

As Xiaobin said in comment 78, the root cause is mozilla tries to call a method
of a destroyed pluginInstance, no matter it's NULL or something else invalid.

Comment 83

[Kyle Yuan]

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

Comment 84

[Kyle Yuan]

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

Comment 85

[Xiaobin Lu]

This bug has been fixed in JRE 1.5 release which will be release sometime next 
year. 

Comment 86

[Asa Dotzler [:asa]]

Unable to reproduce crash with Mozilla 1.7 beta on windows XP and JRE 1.5 beta.

Comment 87

[David G King]

v'ing