The default bug view has changed. See this FAQ.

Firefox 14 alpha1 hangs on this page www.cyscape.com/showbrow.asp

RESOLVED FIXED in Firefox 14

Status

()

Core
Widget
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Bader Zaidan, Assigned: glandium)

Tracking

({regression})

14 Branch
mozilla14
x86
Mac OS X
regression
Points:
---

Firefox Tracking Flags

(firefox14+ fixed)

Details

(Whiteboard: [testday-20120323] [qa+], URL)

Attachments

(5 attachments)

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120323 Firefox/14.0a1
Build ID: 20120323031214

Steps to reproduce:

visited  www.cyscape.com/showbrow.asp 



Actual results:

Firefox 14a1 hangs on this page under Mac OS X Lion and CPU is at 99%


Expected results:

the page should have displayed results of a browser test
(Reporter)

Updated

5 years ago
(Reporter)

Updated

5 years ago
(Reporter)

Comment 1

5 years ago
this bug is only present under firefox nightly 14 alpha 1.

the cpu is at 99% and is at 89 degrees celcius.
after i force close firefox have to stop the process under activity monitor
Juan was able to reproduce this on Nightly on Mac OSX Lion.
I was unable to reproduce this on Windows 7 and Fedora 16.
It would appear this bug is restricted to Nightly Mac builds.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regressionwindow-wanted
Whiteboard: [testday-20120323]
I was able to reproduce this on the nightly (Fx14) but if I disable the Java Applet Plugin allows the page to finish loading, and things seem just as in Fx10, 11 or 12.
(Reporter)

Comment 4

5 years ago
Further tests prove that it only hangs under Mac OS X lion in Firefox nightly 14 alpha 1 when java enabled.
IF you change the browser version or disable java it will not hang.

Updated

5 years ago
tracking-firefox14: --- → +
Component: Untriaged → Widget
Product: Firefox → Core
QA Contact: untriaged → general

Comment 5

5 years ago
(In reply to LightWaveX from comment #4)
> Further tests prove that it only hangs under Mac OS X lion in Firefox
> nightly 14 alpha 1 when java enabled.
> IF you change the browser version or disable java it will not hang.

Sending over to Core::Widget - if changing the UA has an effect, can we diff the source we get depending on the UA to see what specifically changes?
(Reporter)

Comment 6

5 years ago
First Bad: 2012-03-23, Last Good: 2012-03-22, 

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-03-22&enddate=2012-03-23
Thanks LightWaveX
Keywords: regressionwindow-wanted → regression
Based on the changeset:
http://hg.mozilla.org/mozilla-central/rev/ab2ff3b5611f

Appears to be a regression from:
Bug 736752 - Compartment mismatch in JetPack 'test-content-proxy.testTypedArrays', r=bholley
(Reporter)

Comment 9

5 years ago
> if changing the UA has an effect, can we diff
> the source we get depending on the UA to see what specifically changes?

I attempted to change the useragent but the 'User Agent Switcher' addon is not supported.
(Reporter)

Comment 10

5 years ago
I successfully installed UA switcher.

If you set the UA to Internet explorer 6 7 or 8 page does not redirect after test like it is supposed to , but the browser does not hang, crash or display errors.

If you set the user agent to iphone 3.0,  hang occurs.
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #8)
> Based on the changeset:
> http://hg.mozilla.org/mozilla-central/rev/ab2ff3b5611f
> 
> Appears to be a regression from:
> Bug 736752 - Compartment mismatch in JetPack
> 'test-content-proxy.testTypedArrays', r=bholley

roc - do you agree with Anthony's hypothesis here?
Created attachment 610629 [details]
a diff of the source when using FF and IE UAs
(In reply to Alex Keybl [:akeybl] from comment #11)
> roc - do you agree with Anthony's hypothesis here?

It doesn't look like the page touches canvas at all, which is all that patch touches.

Nothing out in that regression range jumps out at me though.

It sounds like the problem is related to the Java plugin (comment #4). Josh, Stephen, can you reproduce this?
Created attachment 610750 [details]
Hang Report from 10.7

Attaching the hang report from that site in case it is useful.
Looks like we're just hanging in the Java plugin. No idea why that would have regressed.
Created attachment 610901 [details]
hang backtrace

I just got a hang and it appears to be the same one as here. i.e. mine also happens in SetWindow. The concerning part is that it appears the plugin calls 'Java_java_lang_UNIXProcess_forkAndExec' which I don't think you ever want to do within firefox, right?
Created attachment 610907 [details]
"call (void) pss()" results (Java stack)
> The concerning part is that it appears the plugin calls 
> 'Java_java_lang_UNIXProcess_forkAndExec' which I don't think you ever want to do
> within firefox, right?

Nope, that's alright.  The Java plugin always runs in-process on the Mac.  (It's parent process does, that is.  But the Java plugin parent process also spawns its own child process.)

By the way, please post the result of "thread apply all bt" (before you've done "call (void) pss()").
A quick look at the output of pss() suggests this isn't a Java hang ... so it may be our fault.

I've got a bunch of topcrashers on my plate, so I won't really be able to dig into this until next week.  But I'll try to reproduce later today.

I'm taking this bug, now -- I'm the resident Java guy.  But I won't cry if someone else figures it out before I have a chance to get to it.
Assignee: nobody → smichaud
I can reproduce this crash 100% with a nightly-profiling build but not my local build. Someone else should try it with that build.

Running 'Java Applet Plug-in 14.0.3'.
Benoit, what version of OS X are you testing with?  Is it Lion?
10.7.2, so not the latest (haven't rebooted in months).
Bug 739259 is likely a dupe of this and has a regression window.

Comment 24

5 years ago
Looks like a dupe of bug 739259. It happens with Snow Leopard too, 10.6.8. 

When entering a page with Java-applet Firefox will create a child process of the firefox binary, but no plugin process for the Java Plugin. If you force quit the child process it will recreate it. Only way to properly quit Firefox is to force quit the parent process and then the child process.
On mozilla.dev.platform, another way of reproducing this hang (same regression range) was provided:

On 12-03-30 12:21 PM, Patrick Brunschwig wrote:
> I'm using fork() with js-ctypes for the new subprocess implementation.
> This worked fine until since a few days ago. On Daily (Mac OS X) it
> seems that the child process is consuming a full CPU and does not continue.
> 
> Is it forbidden to use fork(), do I do something wrong, or is this a
> Gecko bug?
> 
> Here is the relevant code:
> 
> 	var fork =<js-cytypes fork()>
> 	var execve =<js-cytypes fork()>
>          pid = fork();
>          if (pid>  0) { // parent
> 	    ...	
>              return pid;
>          } else if (pid == 0) { // child
> 	    ...
>              execve(command, _args, _envp);
>              exit(1);
> 	}
> 	else {
> 	    ...
> 	}
The common element here is forking, which leads me to strongly suspect bug 737084 (Do pthread_atfork in jemalloc on mac and android).
Blocks: 737084
(Assignee)

Comment 27

5 years ago
(In reply to Josh Matthews [:jdm] from comment #26)
> The common element here is forking, which leads me to strongly suspect bug
> 737084 (Do pthread_atfork in jemalloc on mac and android).

I agree. Disabling pthread_atfork on mac should fix it, and break nothing else, because I figured, since bug 737084, that the system zone allocator on mac was calling the locking functions anyways.
(Assignee)

Comment 28

5 years ago
I do wonder why we don't catch that in the test suite, though...
Duplicate of this bug: 741268
Duplicate of this bug: 741603
Bug 741603 has a stack which may indicate that Java needn't be involved.
(Assignee)

Comment 32

5 years ago
Created attachment 612118 [details] [diff] [review]
Don't call pthread_atfork from jemalloc on OSX, the zone allocator already registers functions for pre/post-fork
Attachment #612118 - Flags: review?(justin.lebar+bug)
(Assignee)

Updated

5 years ago
Assignee: smichaud → mh+mozilla
(In reply to Mike Hommey [:glandium] from comment #32)
> Created attachment 612118 [details] [diff] [review]
> Don't call pthread_atfork from jemalloc on OSX, the zone allocator already
> registers functions for pre/post-fork

Mike and I talked about this on IRC.  Although the zone allocator does some locking pre- and post-fork, it's not doing the equivalent of _malloc_prefork's locking.  So someone could come in during fork and allocate directly through jemalloc.

But this patch takes us to where we were before bug 737084, and that didn't randomly deadlock, so it's virtuous.  jemalloc2 will lock correctly here.
Attachment #612118 - Flags: review?(justin.lebar+bug) → review+
(Assignee)

Comment 34

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/e51a6ddc3282
Target Milestone: --- → mozilla14
I'm able to reproduce this bug (using the STR in comment #0) with today's mozilla-central nightly on OS X 10.6.8, with both Java For Mac OS X 10.6 Update 6 and the recently released Update 7.

And I've confirmed that the STR from comment #0 no longer works (on OS X 10.6.8 with Update 7) with the patch from comment #32 applied.

Later I'll test on Lion.
Just to be clear, this hasn't landed on m-c yet, so the fact that Steven can reproduce isn't a problem.  :)
http://hg.mozilla.org/mozilla-central/rev/e51a6ddc3282
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
status-firefox14: --- → fixed
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20100101 Firefox/14.0

No hang on Firefox 14 beta 8 on Mac OS 10.7 Lion here and CPU usage normal, but couldn't reproduce the problem with a build from the report date either. I'll leave it for someone who could reproduce initially to verify.
Whiteboard: [testday-20120323] → [testday-20120323] [qa+]
You need to log in before you can comment on or make changes to this bug.