77714 - Mac crashes when closing after java site.

Status: VERIFIED WORKSFORME

(Core Graveyard :: Java: OJI, defect)

Description

[John Unruh]

1.) Visit a site with java like http://www.sj-downtown.com.
2.) Click Back, then on File, Quit.
What happens: The browser crashes.

Comment 1

[Terry Noyes]

The _particular_ variation works, perhaps due to today's fixes for bug #76936
and bug #79872.  However, bug #81631, quitting with an applet running, still exists.

Man, loading
http://www.mozilla.org/quality/browser/front-end/testcases/oji/test2.html takes
forEVER now.

Comment 2

[Terry Noyes]

The bug is back today (with a late build from 21May) but with a different crash
signature.  Probably all the LiveConnect work and lazy-loading of Java stuff
getting hashed out.

Last few calls in the stack crawl:
nsPluginHostImpl::Destroy()+34
nsActivePluginList::stopRunning()+48
MRJPluginInstance::SetWindow(nsPluginWindow*)+28
MRJContext::setWindow(nsPluginWindow*)+8c
MRJContext::synchronizeClipping()+a4 .... then crash in NQDSetRectRgn

Comment 3

[Terry Noyes]

when quitting after close, nsActivePluginList::stopRunning()
calls MRJPluginInstance::SetWindow() with a nil window a second time
(the first was during close of window) but
the attempted MRJPlugin.cpp;line #743 'mContext->setWindow(pluginWindow);'
is doomed to failure as this->mContext is nil by now.

Comment 4

[Terry Noyes]

oops, I meant that SetWindow is called a second time. 
nsActivePluginList::stopRunning isn't involved when the window gets closed.

In any case, mContext has been set to null, and MRJPluginInstance::SetWindow()
and MRJPluginInstance::Stop() (which have already been called) aren't expecting
that.

As a workaround, putting 'if (mContext)' checks in those two routines prevents
today's 77714 crash.

Comment 5

[Terry Noyes]

Attachment: quickie work-around for today's incarnation of 77714

Comment 6

[Terry Noyes]

bug has disappeared in build from morning of 5.29.01

Comment 7

[drapeau]

Updating Status Whiteboard to indicate a bug actively being worked on by Terry.

Comment 8

[Terry Noyes]

stack crawl has now changed (6/14 am build) to
nsJVMManager::Release()+18
nsJVMManager::Internal::Release()+48

Comment 9

[Terry Noyes]

Both bug 77714 and bug 81631 have gone away on my 2001062210 build.
Perhaps the LiveConnect stuff has gotten settled.

Comment 10

[John Unruh]

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

Comment 11

[Terry Noyes]

It is not a duplicate, though.  Using recent builds, bug 77714 still happens on one of my B&W G3's but not on my iMac.  Bug 81631 seems to have disappeared.  In any case, the crash signatures of the two are completely different, and 77714 is patchable, though I've no satisfying solution.

Comment 12

[John Unruh]

Reopening. Not really a dupe, and still reproducible.

Comment 13

[John Unruh]

Worksforme with the 7/25 Mac RTM build.

Comment 14

[John Unruh]

Verified worksforme.