Closed Bug 741448 (jsperf-hang) Opened 12 years ago Closed 7 years ago

running jsperf.com hangs nightlies (Fx 14) due to java plug-in

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(firefox14-)

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox14 - ---

People

(Reporter: dmosedale, Unassigned)

References

(
URL
)

Details

On OS X, the browser beachballs and has to be killed.

Aurora (Fx13) does not have this problem.

This makes figuring out whether nightlies have improved or regressed on such tests impossible.

As far as I can tell, it happens with any jsperf.com performance test.  As an example, I see it with <http://jsperf.com/float32array-vs-properties>.
This happens to me on all sites that include Java applets, since about one week.
An jsperf.com does indeed use a Java applet for nanosecond timing.  Good times!  Resetting the component to something that is more likely to be appropriate.
Assignee: general → blackconnect
Component: JavaScript Engine → Java-Implemented Plugins
QA Contact: general → blackconnect
Not quite the right component.... that one is for plug-ins implemented in Java, not for the Java plug-in.  ;)

This looks like a dup of the fork() hang.

dmose, I'd just disable Java for now to make jsperf (and the web at large!) usable.
Assignee: blackconnect → nobody
Component: Java-Implemented Plugins → Plug-ins
QA Contact: blackconnect → plugins
Whiteboard: DUPEME
Summary: running jsperf.com hangs nightlies (Fx 14) → running jsperf.com hangs nightlies (Fx 14) due to java plug-in
> This looks like a dup of the fork() hang.

Which is bug 738709 (and probably also some others).
See Also: → 738709
> dmose, I'd just disable Java for now to make jsperf (and the web at large!) usable.

This seems more than a little too drastic.

Bug 738709 comment #27 suggests that the best quick fix is to "disable pthread_atfork on mac", by (partially) backing out the patch for bug 737084.
That's not exactly an option for those of us running nightlies.
(In reply to comment #6)

I thought you were suggesting we disable Java in those nightlies! :-)

Apparently you're just suggesting that we tell users to disable Java until this problem is cleared up.

That's fine with me.

I'm still stuck on another topcrasher (bug 738640).  But I should be able to get to bug 738709 and friends later this week.
Oh, yes.  I was talking about "go into about:addons and disable Java there".  ;)
Gah.  This is NOT fixed by the fix for bug 738709.  Or at least it certainly happens in an April 16 nightly.  I hadn't realized that it was still happening, since I've had Java disabled.

Nominating this for tracking.  We can't ship this, unless we want what few web developers still use Firefox on Mac to stop.

Symptoms:  When loading the url in comment 0, I get a message on the console saying "Process manager already initialized -- can't fully enable headless mode." and then the browser hangs.  Sometimes it does this with 100% CPU, sometimes with 0% CPU.

Note that I get the 0% CPU hang on the url from bug 738709 as well.
Severity: normal → critical
tracking-firefox14: --- → ?
Whiteboard: DUPEME
I don't have any trouble with this bug's URL (http://jsperf.com/float32array-vs-properties), using today's mozilla-central nightly on OS X 10.6.8.

But I also haven't yet installed Apple's latest Java update (Update 8 for 10.6).  Which OS are you using, and which Java update do you have?  (*Don't* give me the results of "java -version".  Instead look at your installed updates in Software Update.)

The previous set of Apple's Java updates (Update 7 for 10.6 and 002 for 10.7) fixed the Java bug that's been actively exploited.  The current set (Update 8 for 10.6 and 003 for 10.7) add the capability of removing trojans.  I'm still using the previous set (as I kind of expected Apple to get things wrong in the latest set).
URL: http://jsperf.com/float32array-vs-pro...
Likewise on OS X 10.7.3 -- no problems with this bug's URL.
I'm on 10.6.8, on Java Update 8.
Have you made sure Java is enabled (at the OS level)?  Apple's descriptions of their latest updates suggest they periodically disable Java.

I'll install Update 8 to play with.  But first I need to install a fresh copy of OS X 10.6.8 on a spare partition.  I don't want to mess up the installation I actually use :-)
One more thing, Boris:

Did you go straight from Java Update 6 to Update 8?  Or did you update first to Update 7?
> Have you made sure Java is enabled (at the OS level)?

No.  Where do I check that?

> Did you go straight from Java Update 6 to Update 8?  Or did you update first to Update 7?

I believe the latter (or at least the "Installed Software" tab in "Software Update" preferences lists both 7 and 8).

I just checked my own debug 32-bit build, pulled from inbound today, and it seems to work fine.  This morning's nightly still does not.  So I can't get any useful debug info so far, but maybe the universal binary thing matters somehow?

I did look at a sample of the hung process.  It's under nsObjectLoadingContent::InstantiatePluginInstance calling nsHTMLPluginObjElementSH::SetupProtoChain calling nsNPAPIPluginInstance::GetJSObject calling nsNPAPIPluginInstance::GetValueFromPlugin and then down into the applet code which is doing who knows what.  The sample claims JVM_MonitorWait for half the callstack, so it might just be lying based on the few exported symbols it sees.
I'm not seeing this problem in this morning's nightly, OS X 10.7.3.  I'm didn't see an "Installed Updates" page in the "Software Update" app, so I'm not sure what version of Java I've got.  IIRC, Software Update updated Java for me at least twice in the last week.
Dan, the "Installed Updates" thing is in the "Software Update" section of System Preferences, not in the Software Update app itself.
The most recent Java installs on my 10.7.3 box are 2012-003, 002, and 001.
>> Have you made sure Java is enabled (at the OS level)?
>
> No.  Where do I check that?

I don't know for the latest updates (which I still haven't installed myself).

For previous versions I imagine you disable Java by unchecking all the boxes in the General tab of Applications : Utilities : Java Preferences.
Where is the Applications thing?
Boris, you might be seeing something like bug 735425 (or some other similar bugs -- I'll get their numbers later).

If you can repro the hang in a recent profiling build, attach to the main process with gdb and try the following, in this order:

1) Get the output of "thread apply all gdb".
2) Get the output of "call (void) pss()".

The output of the second might go to an unexpected location -- for example to the Console app (instead of into Terminal).

> Applications : Utilities : Java Preferences

/Applications/Utilities/Java Preferences.app :-)
> Boris, you might be seeing something like bug 735425 (or some other
> similar bugs -- I'll get their numbers later).

Another is bug 717986.
> 1) Get the output of "thread apply all gdb".

"thread apply all bt", of course :-(
(In reply to comment #15)

From what you say, looks like you're seeing bug 717986.  Take a look at Ehsan's traces there.
Boris, I've finally got Java for Mac OS X Update 8 installed on my spare 10.6.8 partition ... and I can't reproduce what you report.

I *can* reproduce bug 717986.  But that was already reproducible a while ago.

The chances are very good that you're seeing bug 717986.

In any case, Apple's latest Java updates don't seem to have "broken" Java in FF.  Though you really had me worried for a while :-)
By the way, Update 8 didn't provide any new way to disable Java system-wide.  And when I tried the "old" way (unchecking all the boxes in Java Preferences' General tab) this didn't cause today's mozilla-central nightly to hang.  You just see blank space where the Java applet should be.
Boris, the hang at bug 717986 turns out to happen when we try to load an illegal APPLET tag.  I'd guess that isn't what's happening to you ... though tell me if I'm wrong.

So your hangs are still a mystery.

But at least we have good reason to believe they don't happen to everyone using Apple's latest Java updates.
Hmm.  I restarted my nightly, and now things no longer hang.  Do you think this could have been an issue with multiple browsers all trying to run Java at the same time?
> Do you think this could have been an issue with multiple browsers
> all trying to run Java at the same time?

No, I don't.

My best guess is you triggered some kind of Java error, and that's
what caused/triggered the hangs.  This is what happens at bug 717986.
There's also bug 708461, but those hangs don't happen on startup, and
also happen (at	least to some extent) in other browsers.

I'll try to find time tomorrow or next week to dig further into these
issues.
Do we think that there changes have been made server side, or that this is an intermittent bug?

We can add the qawanted keyword if we'd like more attempts at reproductions.
It's not quite clear what's going on here.  Modulo whatever issue I was seeing that went away when I restarted my browser, this might have just been bug 738709.
I don't think we should be tracking this bug.

We don't have enough evidence to pin down what's going on here.  At best we're just guessing how it might be related to other bugs.
(In reply to Steven Michaud from comment #32)
> I don't think we should be tracking this bug.
> 
> We don't have enough evidence to pin down what's going on here.  At best
> we're just guessing how it might be related to other bugs.

That sounds reasonable. Nothing actionable here, so untracking for release.
tracking-firefox14: + → -
I'm marking this bug as WONTFIX per bug #1269807.

For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.