Mac crashes when closing after java site.

VERIFIED WORKSFORME

Status

Core Graveyard
Java: OJI
VERIFIED WORKSFORME
17 years ago
7 years ago

People

(Reporter: John Unruh, Assigned: Terry Noyes)

Tracking

Trunk
PowerPC
Mac System 9.x

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: oji_working, URL)

Attachments

(1 attachment)

(Reporter)

Description

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

Updated

17 years ago
QA Contact: shrir → junruh
(Assignee)

Comment 1

17 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 2

17 years ago
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
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Comment 3

17 years ago
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.
(Assignee)

Comment 4

17 years ago
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.
(Assignee)

Comment 5

17 years ago
Created attachment 35628 [details] [diff] [review]
quickie work-around for today's incarnation of 77714
(Assignee)

Comment 6

17 years ago
bug has disappeared in build from morning of 5.29.01

Comment 7

17 years ago
Updating Status Whiteboard to indicate a bug actively being worked on by Terry.
Whiteboard: oji_working
(Assignee)

Comment 8

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

Comment 9

17 years ago
Both bug 77714 and bug 81631 have gone away on my 2001062210 build.
Perhaps the LiveConnect stuff has gotten settled.
(Reporter)

Comment 10

17 years ago

*** This bug has been marked as a duplicate of 81631 ***
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 11

17 years ago
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.
(Reporter)

Comment 12

17 years ago
Reopening. Not really a dupe, and still reproducible.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Comment 13

17 years ago
Worksforme with the 7/25 Mac RTM build.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 14

17 years ago
Verified worksforme.
Status: RESOLVED → VERIFIED

Updated

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