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)

8 Branch
All
macOS
defect
Not set
critical

Tracking

(firefox9 verified, firefox10 verified)

RESOLVED FIXED
mozilla11
Tracking Status
firefox9 --- verified
firefox10 --- verified

People

(Reporter: marcia, Assigned: smichaud)

References

()

Details

(Keywords: crash, verified-beta, Whiteboard: rdar://10444452 [inbound][qa!])

Crash Data

Attachments

(1 file)

+++ 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.
No longer depends on: 700835
No longer blocks: 670079, 701148, 701537
Assignee: nobody → smichaud
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/
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.
Attached patch FixSplinter Review
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)
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.
> 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?
Comment on attachment 579702 [details] [diff] [review]
Fix

If people prefer, I could make this change specific to OS X.
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.
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.
> 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 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+
Attachment #579702 - Flags: approval-mozilla-beta?
Attachment #579702 - Flags: approval-mozilla-aurora?
Whiteboard: rdar://10444452 → rdar://10444452 [inbound]
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+]
https://hg.mozilla.org/mozilla-central/rev/b6e94c784c53
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
Blocks: 702238
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]
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.
> 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.
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!]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: