14712 - Loading photocube applet twice crashes apprunner.

Status: CLOSED FIXED

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

Description

[Leila Garin]

Using my Sept. 14 Mozilla build and jdk1.3 on WinNT.
Note: On MAC with MRJ Plugin, it works fine.

To reproduce,
- Bring up the apprunner.
- Load http://passage/browser/src/Applets/Misc/html/cubes/photocube/index.html.
- Load another page.
- Load again the same photocube applet.

  The applet would not be started again properly. Then, the Application Error
  dialog would come up with "..... The memory could not be read" message.
  Sometimes, you would need to resize or scroll the window first in order to
  cause the application error dialog to show up.

Comment 1

[edburns]

Still get this bug, Get this console error from the VM:


#
# HotSpot Virtual Machine Error, EXCEPTION_ACCESS_VIOLATION
#
# Error ID: 4F533F57494E13120E43505002B7
#

Robert do you know what this is?

Comment 2

[Robert H. Yang]

I can repro this.  Looks like the crash occurs in AWT, related to classes_2d
apparently.  I'll file a bug.

BTW I repackaged the class and images to run locally, and ran with a typical
Java Plugin HTML page (OBJECT/EMBED tags).  I didn't observe this problem with
NS4.x or MSIE5.  I suspect something different is occurring with the refresh
button under Mozilla than under the other browsers.  Can somebody let me know
what happens in OJI when "Refresh" gets hit ?

Comment 3

[Robert H. Yang]

I also notice the following in the Java Console when I load the applet and then
hit Refresh :

	java.lang.NullPointerException
		at image3dcube.run(Unknown Source)
		at java.lang.Thread.run(Thread.java:488)

To elaborate on my earlier query, what calls on OJI methods are made
when "Refresh" is hit in Mozilla, and similarly what happens when the user
leaves the page for another, and then returns ?

Comment 4

[edburns]

Robert, I don't know if you'll like this answer, but I've instrumented
nsJVMManager.cpp, jvmmgr.cpp and ProxyJNI.cpp to print out the function name of
each function as it is called and here's what I see on reload:

Document http://www.javapplets.com/special/Curtain.htm loaded successfully
Document: Done (29.653 secs)
Going to reload
+++  nsJVMManager::AggregatedQueryInterface()

+++  nsJVMManager::IsJavaEnabled()

+++  nsJVMManager::GetJVMStatus()

+++  nsJVMManager::EnsurePrefCallbackRegistered()

+++  nsJVMManager::AggregatedQueryInterface()

+++  nsJVMManager::InitLiveConnectClasses()

InstantiateEmbededPlugin for application/x-java-vm
InstantiateEmbededPlugin find stopped
flashReload(http://cvs-mirror.mozilla.org/webtools/tinderbox/SeaMonkey/flash.rdf
, 300)
Document http://www.javapplets.com/special/Curtain.htm loaded successfully
Document: Done (21.461 secs)

Pretty much as expected.

Comment 5

[edburns]

Robert: the same set of methods are invoked when returning to a previously
visited applet page, or even a non-applet page.  I'm not sure this is an
exhaustive answer though.  Can you do some investigation to answer your own
question as well?

Comment 6

[Robert H. Yang]

I found out why the JPI behaves differently under Mozilla vs. NS4.

Under NS4 the JPI maps NPP_Destroy() to nsIPluginInstance::Stop() followed by a
call to nsIPluginInstance::Destroy().  The NPP_Destroy() comes in when a
refresh happens or the user browses to another page.

Under Mozilla, the JPI gets no calls to these methods after a refresh, but does
get a call to nsIPluginInstance::SetWindow( NULL ), which is called from
NPP_SetWindow().

What is the correct sequence of OJI calls to expect under Mozilla in this
situation ?

It might also be interesting to note the correct correspondence between
nsIPluginInstance methods vs. the old Plugin API calls.

Comment 7

[Robert H. Yang]

Correction :
>Under Mozilla, the JPI gets no calls to these methods after a refresh,
>but does get a call to nsIPluginInstance::SetWindow( NULL ), which is
>called from NPP_SetWindow().

The NPP_SetWindow() call occurs in NS4 (duh  8)

Comment 8

[edburns]

ryang wrote:

> What is the correct sequence of OJI calls to expect under Mozilla in this
> situation ?

Do you mean Calls from OJI to JPI?

Comment 9

[Robert H. Yang]

Yes, exactly.

More to the point, why do the nsIPluginInstance::Stop/Destroy calls not come in
under Mozilla, while in the same situation under NS4 the NPP_Destroy() does ?

Comment 10

[edburns]

Robert,

I know this is asking a lot, and if you can't answer this question, I can
figure it out somehow, but, can you give me a list of exactly what calls from
OJI to the JavaPlugin must occurr and under what circumstances the call is
made?  Something like

call                                    when called

nsIPluginInstance::Start()              After the page is loaded
nsIPluginInstance::Destroy()            When another page is visited,

etc.

Thanks,

Ed

Comment 11

[Robert H. Yang]

I don't claim to know what calls *should* be occurring, but currently the
Netscape version of the Java Plugin implements the "old" (NS4.x) plugin NPP_*
entry points by making calls into OJI.  The "backward adapter" code might be a
good place to start.  I'll send you the files privately.

Comment 12

[edburns]

It appears that nsIPluginInstance::Stop() is not called, and never has been.

It's possible that the reason "it worked before" was something else was masking
the fact that nsIPluginInstance::Stop() was never called and allowed the plugin
to work when it shouldn't have.

I'm attaching a patch to mozilla/modules/plugin/nglsrc/nsPluginHostImpl that
prints out a statement when each of the methods in nsIPluginInstance are
called.  Note that the following methods of nsIPluginInstance are never called
under any circumstances:

    Stop

    Print

    GetValue (called in ns4xPlugin)

    HandleEvent

I think this is a bug.

av, can you please help with this?  Can I assign this to you?

Ed

Comment 13

[edburns]

Attachment: debugging statements.

Comment 14

[edburns]

Attachment: Send the Stop() message to nsIPluginInstance at the appropriate time.

Comment 15

[edburns]

Robert, the latest patch causes mozilla to send the Stop() message to the
plugin at the right time.

However, I still get the null pData stuff.  Can you please apply this patch to
your mozilla and retry the bug?

Thanks,

Ed

Comment 16

[Robert H. Yang]

A page refresh under NS4.x calls NPP_Destroy(), which calls
nsIPluginInstance::Stop() and Destroy() in the Java Plugin as it is now.  If
your patch could call Destroy() after calling Stop() and then release the
nsIPluginInstance ptr I think that would be more compatible.

Comment 17

[edburns]

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

Comment 18

[Paul Wyskoczka]

This applet does not load using the 1999120608-M-12 build.

Comment 19

[Andrew A. Lyamov]

Attachment: send the Stop() message before the View is destroyed

Comment 20

[Paul Wyskoczka]

Cannot check because java is not enabled in the latest builds

Comment 21

[leger]

Adding "crash" keyword to all known open crasher bugs.

Comment 22

[edburns]

Can't test until this is fixed.

Comment 23

[edburns]

This web server from which this applet is no longer responding.  Raju, can you 
please talk to Leila and get the code from her and get the applet running?  
Than can you please test this bug using the following steps:

02 March 00

Here are the steps I took to enable the viewing of applets in mozilla.

STEP 8 IS THE MOST IMPORTANT, and UNUSUAL step.

1. Check tinderbox to see that it's green for win32 clobber

2. Checkout SeaMonkey at around 11:30am on 02 March 2000

3. Built Mozilla with MOZ_DEBUG=1

4. Used the WINNT Add/Remove programs feature to remove any JRE and JDK
   instance I had installed on my machine.  Then I rebooted.

5. Used a find command to make sure there were no instances of any of
   the following files on my C: drive:

   jpins32.dll
   npjava*.dll
   jpishare.dll
   jaws.jar

   This step is also intended to catch the case where you have Netscape
   Navigator 4.x with the Java plugin installed, which I don't.  If you
   do, you must make sure that you don't have the plugin installed.

6. Downloaded the JRE Release Candidate (RC) 1 release by visiting:

   http://developer.java.sun.com/developer/earlyAccess/j2sdk13/
  
   And choosing the "One large bundle" option under the heading

     Internationalized version of Java 2 Runtime Environment 

7. Ran the installer exe.

8. Unzipped George's zip file on top of the install location, which for
   me was C:\Program Files\JavaSoft\JRE\1.3 .

9. Copied C:\Program Files\JavaSoft\JRE\1.3\bin\npjava*.* to my mozilla
   plugins directory, which is:

   D:\Projects\mozilla\dist\WIN32_D.OBJ\bin\plugins

10. Ran 

   D:\Projects\mozilla\dist\WIN32_D.OBJ\bin\mozilla.exe

After doing the profile manager dance, I was able to view applets
without java-related crashes.


-------------------------

I'm assigning this to you so we don't lose track of it.

Comment 24

[rpallath]

Attachment: Added Tar file for example

Comment 25

[edburns]

Rajendra,

I can get it to crash.  

Opening http://passage/browser/src/Applets/Misc/html/cubes/photocube/image1.jpg
proxy=webcache-cup.eng.sun.com:8080
Opening http://passage/browser/src/Applets/Misc/html/cubes/photocube/image2.jpg
proxy=webcache-cup.eng.sun.com:8080
Opening http://passage/browser/src/Applets/Misc/html/cubes/photocube/image3.jpg
proxy=webcache-cup.eng.sun.com:8080
Opening http://passage/browser/src/Applets/Misc/html/cubes/photocube/image4.jpg
proxy=webcache-cup.eng.sun.com:8080
Opening http://passage/browser/src/Applets/Misc/html/cubes/photocube/image5.jpg
proxy=webcache-cup.eng.sun.com:8080
Opening http://passage/browser/src/Applets/Misc/html/cubes/photocube/image6.jpg
proxy=webcache-cup.eng.sun.com:8080
#
# HotSpot Virtual Machine Error, EXCEPTION_ACCESS_VIOLATION
#
# Error ID: 4F533F57494E13120E43505002BE
#
###!!! ASSERTION: RDFXMLDataSourceImpl not thread-safe: 'owningThread == NS_Curr
entThread()', file E:\Projects\mozilla\xpcom\base\nsDebug.cpp, line 372

E:\Projects\mozilla\dist\WIN32_D.OBJ\bin>

I'm going to ask Stanley to look at it.

Stanley, can you see if you can reproduce this crash.

I've got mozilla from 03/09/00.

Ed

Comment 26

[edburns]

This crashes with Stanley's 03/13 patch with kestrel RC1 and mozilla beta 1 
branch pulled this morning.

Comment 27

[stanley.ho]

I am able to reproduce this problem. This sounds like AWT/Browser race condition 
again. I will look into it more after Beta 1.

Comment 28

[drapeau]

Nominating for Beta 2 status.  Either it's fixed by the latest Java Plug-In and
JDK release, or it's related to the lifecycle problem in the Plug-In module. 
Stanlejy, can you assess current status, please?

Comment 29

[leger]

Putting on [nsbeta2-] radar. Not critical to beta2.  Put, yes, we'll take the 
plugin.

Comment 30

[edburns]

Removing CRASH keyword.  As of Mozilla code from 4 Sept 00 and java plugin code 
from 2 Sept 00, this test no longer crashes, just causes a momentary hang.

Comment 31

[stanley.ho]

This is related to the applet lifecycle bug again. It has been fixed.

Comment 32

[edburns]

Stanley, it hasn't been fixed until we have a Java Plugin that honors 
the "don't cache and do call setwindow after destroy" protocol.