16296 - Applet crashes mozilla

Status: VERIFIED DUPLICATE of bug 27486

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

Description

[Leila Garin]

Using 10/11/99 build of Mozilla on WinNT and jdk1.3 early access release.
This doesn't happen on MAC.

To reproduce,
- Load
http://lonely/blackwood_qa/src/OJI/PluginTest/sunw/Proxy/html/LoadUrlApplet.html
- In the textbox, enter a valid or non-valid URL. Or, the URL pop-up menu,
  choose an item.

  The applet takes the string in the textbox or in the menu, turn it into
  a URL object and loads it. However, the viewer couldn't load the page,
  and freezes.


Using the test below, an applet that directly loads the URL, the above bug
doesn't occur.
http://lonely/blackwood_qa/src/OJI/PluginTest/sunw/Proxy/html/RedirectUrlApplet.html

Comment 1

[edburns]

Excellent work Leila.  I like this applet.  It takes a very long time to load
though.  I am seeing the problem, however.

Thanks,

Ed

Comment 2

[edburns]

Still seeing the problem.

Comment 3

[edburns]

This works with the latest JRE1.3 and today's mozilla build on windows. However
there is disturbing console output:

CacheHandler file name: null
Opening http://lonely/blackwood_qa/src/OJI/PluginTest/sunw/Proxy/classes/Searche
r$1.class proxy=webcache-cup.eng.sun.com:8080
created stream for http://lonely/blackwood_qa/src/OJI/PluginTest/sunw/Proxy/clas
ses/Searcher$1.class
killing stream for http://lonely/blackwood_qa/src/OJI/PluginTest/sunw/Proxy/clas
ses/Searcher$1.class
CacheHandler file name: null
Inside Text Fields Action Listener....
 URL String is http://www.mozilla.org/
http://www.mozilla.org/
java.lang.NullPointerException: null pData
        at sun.awt.windows.WComponentPeer.hide(Native Method)
        at java.awt.Component.hide(Unknown Source)
        at sun.applet.AppletPanel.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)Exception in thread "main"
java.lang.NullPointerException: null pData
        at sun.awt.windows.WComponentPeer.hide(Native Method)
        at java.awt.Component.hide(Unknown Source)
        at java.awt.Window.hide(Unknown Source)
        at java.awt.Component.show(Unknown Source)
        at java.awt.Component.setVisible(Unknown Source)
        at sun.plugin.navig.win32.PluginObject.setWindow(Unknown Source)
java.lang.NullPointerException: null pData
        at sun.awt.windows.WComponentPeer.hide(Native Method)
        at java.awt.Component.hide(Unknown Source)
        at sun.applet.AppletPanel.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
Document http://www.mozilla.org/ loaded successfully
Document: Done (2.524 secs)

And the browser freezes with even more disturbing console output when I press
back to visit the original applet page.

Going Back
InstantiateEmbededPlugin for application/x-java-vm
Exception in thread "main" java.lang.NullPointerException: null pData
        at sun.awt.windows.WComponentPeer.hide(Native Method)
        at java.awt.Component.hide(Unknown Source)
        at java.awt.Window.hide(Unknown Source)
        at java.awt.Component.show(Unknown Source)
        at java.awt.Component.setVisible(Unknown Source)
        at sun.plugin.navig.win32.PluginObject.setWindow(Unknown Source)
java.lang.NullPointerException: null pData
        at sun.awt.windows.WComponentPeer.show(Native Method)
        at java.awt.Component.show(Unknown Source)
        at sun.applet.AppletPanel.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
java.lang.NullPointerException: null pData
        at sun.awt.windows.WFramePeer.getState(Native Method)
        at java.awt.Frame.getState(Unknown Source)
        at java.awt.Frame.removeNotify(Unknown Source)
        at java.awt.Window$1$DisposeAction.run(Unknown Source)
        at java.awt.Window.dispose(Unknown Source)
        at sun.plugin.navig.win32.PluginFrame.windowClosing(Unknown Source)
        at java.awt.Window.processWindowEvent(Unknown Source)
        at java.awt.Window.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)


Ed

Comment 4

[Robert H. Yang]

The Java Plugin and Mozilla do not currently cooperate when the applet is
stopped.  See bug 14712 for questions on the OJI call sequence.  The applet
isn't being issued the OJI calls it expects.  This needs to be resolved before
something like this can work.

Comment 5

[edburns]

this might turn out to be a DUP of 14712.

Comment 6

[edburns]

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

Comment 7

[edburns]

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

Comment 8

[edburns]

  Modified java.awt.Component.hide() to print out the current thread
  name.  Using this and the stack trace, I have found the reason for the
  null pData and subsequent crash of the VM.

  When the user presses "back" the nsPluginInstanceOwner destructor is
  called.  This calls 

    mPluginHost->StopPluginInstance(mInstance);
    mInstance->Stop();
    mInstance->SetWindow(nsnull);

  SetWindow(nsnull) causes the applet to receive the hide message.  This
  happens in java thread "main".

  Then, AppletPanel, while going through its run() method, processes the
  APPLET_STOP event.  This sends applet.hide(), which eventually comes
  to awt_Component.cpp: Java_sun_awt_windows_WComponentPeer_hide().
  This is the *second* time this method has been invoked on this
  instance, but this time it's on the "applet" thread.  The first time
  was when we did mInstance->SetWindow(nsnull) (on the "main" thread).
  This method checks for peer data, and finds that it is null (due to
  the SetWindow(null) call), which causes the crash.

  I think someone in the JPI team needs to take these findings and run
  with them.

Comment 9

[edburns]

I've dug a little deeper on this and found that the pData is getting set to 
null in the AwtComponent::UnlinkObjects() c++ method.

AwtComponent::UnlinkObjects() line 3692
AwtComponent::~AwtComponent() line 161
AwtCanvas::~AwtCanvas() line 29 + 8 bytes
AwtWindow::~AwtWindow() line 50 + 8 bytes
AwtFrame::~AwtFrame() line 102 + 8 bytes
AwtFrame::`scalar deleting destructor'(unsigned int 1) + 15 bytes
AwtComponent::WmDestroy() line 1177 + 30 bytes
AwtWindow::WmDestroy() line 386
AwtComponent::WindowProc(unsigned int 2, unsigned int 0, long 0) line 802 + 11 
bytes
AwtComponent::WndProc(HWND__ * 0x000102a6, unsigned int 2, unsigned int 0, long 
0) line 249 + 23 bytes
USER32! 77e71ab7()
USER32! 77e71a77()
NTDLL! 77f7624f()
USER32! 77e71bfe()
AwtToolkit::PumpWaitingMessages() line 712 + 18 bytes
AwtToolkit::MessageLoop() line 667
Java_sun_awt_windows_WToolkit_eventLoop(JNIEnv_ * 0x006201e4, _jobject * 
0x0fc6fd28) line 1448
024db875()
024d93a2()
024d946a()
JVM! 080e276e()
JVM! 0801e79a()
JVM! 080402f2()
JVM! 0801e69f()
JVM! 0801e41d()
JVM! 0802b654()
JVM! 08056df6()
JVM! 08056dc7()
MSVCRT! 7800265a()

This method gets called 4 times (with different pairs of java/c++ objects) when 
the user presses back.  I was unable to establish a correlation between jobject 
addresses in this method and jobject addresses in the awt_Component.cpp _hide() 
jni method that discovers the null pData, but I do think that the reason we get 
the null pData error is that UnlinkObjects has been called on this object.

Stanley, any ideas?

Comment 10

[leger]

Adding "crash" keyword.

Comment 11

[edburns]

The null pData problem is believed to be from 27486.  Thus I'm marking this as 
a dup.

*** This bug has been marked as a duplicate of 27486 ***

Comment 12

[Paul Wyskoczka]

Verified.