Closed
Bug 705931
Opened 13 years ago
Closed 13 years ago
[Mac] Firefox 8.0.1 crashes when many Java applets are loaded
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(firefox9 verified, firefox10 verified)
RESOLVED
FIXED
mozilla11
People
(Reporter: marcia, Assigned: smichaud)
References
()
Details
(Keywords: crash, verified-beta, Whiteboard: rdar://10444452 [inbound][qa!])
Crash Data
Attachments
(1 file)
1.14 KB,
patch
|
jst
:
review+
akeybl
:
approval-mozilla-aurora+
akeybl
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
+++ This bug was initially created as a clone of Bug #700835 +++ After Bug 700835 was resolved, we still have some residual crashes due to the fact that we haven't yet worked around Apple's bug on pages that have lots of Java applets. The volume on Firefox 8.0.1 is significantly reduced - a quick query for the first two signatures (mozilla::plugins::parent::_forceredraw and @0x0 | mozilla::plugins::parent::_forceredraw) shows under 100 crashes. Bug 700835#c95 indicates Apple still needs to fix this bug, but filing this in case we want to do anything else.
Reporter | ||
Updated•13 years ago
|
Updated•13 years ago
|
status-firefox10:
fixed → ---
status-firefox11:
fixed → ---
status-firefox8:
fixed → ---
status-firefox9:
fixed → ---
Keywords: crash
Whiteboard: rdar://10444452
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → smichaud
Assignee | ||
Comment 1•13 years ago
|
||
Two more sites where this crash is reported (at https://crash-stats.mozilla.com/) to happen on FF 8.0.1. Both use Java menus (each menu item is a separate Java applet) -- which means there can be *lots* of Java applets on a single page: http://www.maxsalleghenytavern.com/ http://www.nine-eleven.com/
Assignee | ||
Comment 2•13 years ago
|
||
I find that increasing the default plugin cache size from '10' to '50' stops crashes happening with the three sites listed here (from this bug's URL and comment #1). I'll do a tryserver build overnight so that others can test it, and then post the patch tomorrow.
Assignee | ||
Comment 3•13 years ago
|
||
Here's a patch that increases the size of the plugin cache from '10' to '50'. As I said in comment #2, I find this is enough to stop these crashes happening on the sites I tested with. A page containing more than 50 Java applets would probably still crash when you left it (or closed its tab/window), but I expect few if any such pages exist "in the real world". Here's a tryserver build to test with: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-b9f4f26b1947/try-macosx64/firefox-11.0a1.en-US.mac.dmg Please test with the following three URLs, and with any additional pages you can find that contain lots of Java applets. Aside from test pages, the pages with the most Java applets are likely to be ones that implement Java menus (as do all of the three following URLs). http://www.maxsalleghenytavern.com/ http://www.nine-eleven.com/ http://www.grandfunkrailroad.com/station.htm Probably the best way to test is to keep clicking on the Java applet menu items to move from page to page. When you leave a page, NPP_Destroy() is called on all the Java applets that it contains.
Attachment #579702 -
Flags: review?(jst)
Reporter | ||
Comment 4•13 years ago
|
||
Steven: Using the build in Comment 3 and testing the sites, I seem to consistently having to force quit when clicking the menus in the second link. When I hit http://www.nine-eleven.com/customer.htm the browser hangs and I get an application error dialog. I am running on 10.7.3. Both times I tested I hit that same site and had to force quit. The other two sites did not seem to be problematic. (In reply to Steven Michaud from comment #3) > Created attachment 579702 [details] [diff] [review] [diff] [details] [review] > Fix > > Here's a patch that increases the size of the plugin cache from '10' to > '50'. As I said in comment #2, I find this is enough to stop these crashes > happening on the sites I tested with. A page containing more than 50 Java > applets would probably still crash when you left it (or closed its > tab/window), but I expect few if any such pages exist "in the real world". > > Here's a tryserver build to test with: > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com- > b9f4f26b1947/try-macosx64/firefox-11.0a1.en-US.mac.dmg > > Please test with the following three URLs, and with any additional pages you > can find that contain lots of Java applets. Aside from test pages, the > pages with the most Java applets are likely to be ones that implement Java > menus (as do all of the three following URLs). > > http://www.maxsalleghenytavern.com/ > http://www.nine-eleven.com/ > http://www.grandfunkrailroad.com/station.htm > > Probably the best way to test is to keep clicking on the Java applet menu > items to move from page to page. When you leave a page, NPP_Destroy() is > called on all the Java applets that it contains.
Assignee | ||
Comment 5•13 years ago
|
||
> Steven: Using the build in Comment 3 and testing the sites, I seem
> to consistently having to force quit when clicking the menus in the
> second link. When I hit http://www.nine-eleven.com/customer.htm the
> browser hangs and I get an application error dialog. I am running on
> 10.7.3.
I've seen this once, too. I don't remember with which of the three
sites. I didn't have to force-quit -- but the hang did take as much
as 30 seconds to resolve.
I'm quite certain it's unrelated -- that it would happen with or
without my patch. But this is difficult to test, since testing
without my patch will trigger this bug's crashes.
Apple didn't update Java on OS X 10.5.8, so Java on 10.5.8 doesn't
have Apple's crash bug. Could you test on OS X 10.5.8 with today's
mozilla-central nightly, and see if you can reproduce the hangs you
report?
Assignee | ||
Comment 6•13 years ago
|
||
Comment on attachment 579702 [details] [diff] [review] Fix If people prefer, I could make this change specific to OS X.
Assignee | ||
Comment 7•13 years ago
|
||
Actually I *can* reproduce Marcia's hang in today's mozilla-central nightly (testing on OS X 10.6.8), without triggering any of this bug's crashes: 1) Visit http://www.nine-eleven.com/customer.htm. None of the Java applets will load, thanks to a Java error (caused by a Java bug in the site). 2) Hover the mouse over one of the Java applets that failed to load (the little boxes on the left). After a few seconds a tooltip will appear: "Error. Click for details" 3) Click on one of the Java applets that failed to load. Firefox will freeze. Sometimes you'll also see an Application Error dialog, telling you "The Application failed to run". Contrary to my earlier report, the hang seems to last forever -- you have to force-quit Firefox. This confirms the hangs have nothing to do with my patch. You also see hangs on OS X 10.5.8, but (in my tests) they only last 10-15 seconds. So I suppose these "permanent" hangs are yet another Apple bug, introduced by their latest Java updates. I'll open a new bug on this today or tomorrow.
Assignee | ||
Comment 8•13 years ago
|
||
Interestingly, just loading http://www.nine-eleven.com/customer.htm in Safari (on OS X 10.6.8) causes it to freeze -- though only for 15-30 seconds. So Apple may actually fix these hangs.
Assignee | ||
Comment 9•13 years ago
|
||
> So I suppose these "permanent" hangs are yet another Apple bug, > introduced by their latest Java updates. I'll open a new bug on > this today or tomorrow. I've just opened bug 708461.
Comment 10•13 years ago
|
||
Comment on attachment 579702 [details] [diff] [review] Fix >diff --git a/dom/plugins/base/nsPluginHost.cpp b/dom/plugins/base/nsPluginHost.cpp >--- a/dom/plugins/base/nsPluginHost.cpp >+++ b/dom/plugins/base/nsPluginHost.cpp >@@ -226,21 +226,23 @@ static const char kPluginsMimeExtKey[] = > PRLogModuleInfo* nsPluginLogging::gNPNLog = nsnull; > PRLogModuleInfo* nsPluginLogging::gNPPLog = nsnull; > PRLogModuleInfo* nsPluginLogging::gPluginLog = nsnull; > #endif > > #define BRAND_PROPERTIES_URL "chrome://branding/locale/brand.properties" > #define PLUGIN_PROPERTIES_URL "chrome://global/locale/downloadProgress.properties" > > // #defines for plugin cache and prefs > #define NS_PREF_MAX_NUM_CACHED_INSTANCES "browser.plugins.max_num_cached_plugins" >-#define DEFAULT_NUMBER_OF_STOPPED_INSTANCES 10 >+// Raise this from '10' to '50' to work around a bug in Apple's current Java >+// plugins on OS X Lion and SnowLeopard. See bug 705931. >+#define DEFAULT_NUMBER_OF_STOPPED_INSTANCES 50 > > #ifdef CALL_SAFETY_ON > // By default we run OOPP, so we don't want to cover up crashes. > bool gSkipPluginSafeCalls = true; > #endif > > nsIFile *nsPluginHost::sPluginTempDir; > nsPluginHost *nsPluginHost::sInst; > > NS_IMPL_ISUPPORTS0(nsInvalidPluginTag)
Attachment #579702 -
Flags: review?(jst) → review+
Assignee | ||
Updated•13 years ago
|
Attachment #579702 -
Flags: approval-mozilla-beta?
Attachment #579702 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 11•13 years ago
|
||
Comment on attachment 579702 [details] [diff] [review] Fix Landed on mozilla-inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/b6e94c784c53
Assignee | ||
Updated•13 years ago
|
Whiteboard: rdar://10444452 → rdar://10444452 [inbound]
Comment 12•13 years ago
|
||
Comment on attachment 579702 [details] [diff] [review] Fix [Triage Comment] Since this is just raising the default number of stopped instances from 10->50, we're comfortable with taking on aurora and beta. Please land asap.
Attachment #579702 -
Flags: approval-mozilla-beta?
Attachment #579702 -
Flags: approval-mozilla-beta+
Attachment #579702 -
Flags: approval-mozilla-aurora?
Attachment #579702 -
Flags: approval-mozilla-aurora+
Whiteboard: rdar://10444452 [inbound] → rdar://10444452 [inbound][qa+]
Assignee | ||
Comment 13•13 years ago
|
||
Comment on attachment 579702 [details] [diff] [review] Fix Landed on aurora and beta: https://hg.mozilla.org/releases/mozilla-aurora/rev/32064a4c698f https://hg.mozilla.org/releases/mozilla-beta/rev/07e3436ad32a
Assignee | ||
Updated•13 years ago
|
status-firefox10:
--- → fixed
status-firefox9:
--- → fixed
Comment 14•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/b6e94c784c53
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
Comment 15•13 years ago
|
||
I've tried this sites in order to verify this bug: http://www.nine-eleven.com/customer.htm http://www.maxsalleghenytavern.com/ http://www.grandfunkrailroad.com/station.htm I've spent over an hour navigating on these sites and Firefox didn't crash nor freeze. Setting resolution to Verified Fixed on: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20100101 Firefox/9.0 beta 6
Keywords: verified-beta
Whiteboard: rdar://10444452 [inbound][qa+] → rdar://10444452 [inbound][qa+][qa!:9]
Comment 16•12 years ago
|
||
I've verified this on: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20100101 Firefox/10.0 beta 1 Navigating on these sites everything behaves as expected: no crashes and no freezes. http://www.maxsalleghenytavern.com/ http://www.grandfunkrailroad.com/station.htm On http://www.nine-eleven.com/customer.htm, the Java applets from comment7 failed to load and when I clicked on the applet, Firefox froze. This behavior wasn't present in Firefox 9b6 when I first verified this - now it's present. I've tried this site with Google Chrome and Safari and the applets weren't load at all.
Assignee | ||
Comment 17•12 years ago
|
||
> On http://www.nine-eleven.com/customer.htm, the Java applets from comment7 failed > to load and when I clicked on the applet, Firefox froze. See comment #7 and comment #9.
Comment 18•12 years ago
|
||
Considering comment16, marking this bug as Verified on Firefox 10b1.
Whiteboard: rdar://10444452 [inbound][qa+][qa!:9] → rdar://10444452 [inbound][qa+][qa!:9][qa!:10]
Whiteboard: rdar://10444452 [inbound][qa+][qa!:9][qa!:10] → rdar://10444452 [inbound][qa!]
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•