* I read everything above and have demonstrated this bug only occurs on 10.4Fx by testing against this official version of Firefox 4/up (not applicable for startup failure) - SPECIFY VERSION YOU TESTED AGAINST:

Bug occurs with tenfourfox beta five, but not 4.0.2. Firefox 5 beta 3 on an Intel Mac is also bug-free.

* Layout bugs MUST be tested against a system WITHOUT hardware acceleration. Go to Help, Troubleshooting Information to see if your test system is accelerated. If your test system IS accelerated, you must make sure it is OFF, OR test on ANOTHER system that isn't. If this is NOT a layout or display bug, you can skip this step.

* This is a startup crash or failure to start (Y/N):

N

* This is a fault of JavaScript acceleration (Y/N): (Use the steps above to find out. Do NOT report if it is not.)

I think so. Apologies if not.

* What steps are necessary to reproduce the bug? These must be reasonably reliable.

Disable all plug-ins and go to http://www.ted.com/ Memory should spike, and the page should not fully display.

* Describe your processor, computer, operating system and any special things about your environment.

G4 7450, iMac 800 MHz, 10.4.11, 768 MB ram

* For crashes or startup failure (optional): paste in any information from Crash Reporter, or if you are able to run 10.4Fx in gdb, paste in the backtrace. You can often do it like this from within Terminal.app:

I've attached the output from the Crash Reporter.

I'm sorry, I can't confirm this bug. Works fine on this G5.

You can try toggling on or off the nanojit and see if it works (as instructed by the crash blurb).

I can't get the crash to occur with 5b1 or 5b2, which hopefully should come out today or tomorrow. However, I do agree there is an underlying bug present here: both 10.4Fx 4.0.2 and Firefox 5 beta, when the plugin is disabled, correctly enable the page to show a Flash-less version. Ours doesn't do that. This isn't a blocker per se, but we need to fix this before Firefox 6.

Seems to be a malloc issue. We'll need to rebuild debug after 5b2.

firefox-bin(1520,0xa000ed88) malloc: * vm_allocate(size=4224712704) failed (error code=3) firefox-bin(1520,0xa000ed88) malloc: error: can't allocate region firefox-bin(1520,0xa000ed88) malloc: set a breakpoint in szone_error to debug firefox-bin(1520,0xa000ed88) malloc: vm_allocate(size=4224712704) failed (error code=3) firefox-bin(1520,0xa000ed88) malloc: error: can't allocate region firefox-bin(1520,0xa000ed88) malloc: * set a breakpoint in szone_error to debug

First pass:

• Our plugin blocker code does seem to prevent this bug.
• The nanojit is not the cause.
• An error 805E0006 appears during the page load. This might be DOM (logically), but I can't find this specific error code.
• The malloc request is absolutely ridiculous. The reason it might not crash the G5 is that the G5 can handle (and reject) such a request without exhausting its addressing space, so it is entirely plausible for it to cause a crash even though it did not for me.
• This only occurs for plugins that are dynamically inserted and started by JavaScript (watching my logs, I see this occasionally on other sites, so TED is not the only one -- but mercifully uncommon). Regular plugin starts don't do this.
• The malloc is calculated in jsfun.cpp:NewArguments() from argc * sizeof(Value). sizeof(Value) in this case is around 8 and argc is some astronomically high figure.
• A catch in NewArguments to immediately return a null object rather than risk the malloc seems to safely wallpaper the issue, but since it doesn't crash for me normally I can't really tell.
• I don't know why 4.0.2 doesn't do this and 5 does, but IPC is undoubtedly part of the answer.

We can ship with the NewArguments catch in an RC and hope that at least it wallpapers things over, since we plan to kill plugins in 6 anyway. We should try to figure out if the DOM error is a red herring or not, since the NewArguments issue catches the real problem too late.

Upgrading to high, since we have to fix this for 5b3/5 final.

0x805E0006 seems to be NS_ERROR_CONTENT_BLOCKED.

WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805E0006: file mozilla-beta/content/base/src/nsScriptLoader.cpp, line 587

http://james-ross.co.uk/mozilla/misc/nserror?0x805E0006 http://mxr.mozilla.org/mozilla-beta/ident?i=NS_ERROR_CONTENT_BLOCKED

Changing summary after our second pass. Attached test case reliably triggers the issue and has no flash anywhere, so this is not plugin related. Instead, the crash occurs with two types of Dojo elements together. However, regular Dojo doesn't do this, only TED's build, apparently.

805E0006 is indeed a red herring; other sites trigger it without issues.

The plugin blocker actually does not fix this, but our patch does, so this is shippable, but it's still pretty bad.

This seems to have been caused by M636296: https://bugzilla.mozilla.org/show_bug.cgi?id=636296

Kludge in place which appears to work but let's not check this in until Mozilla says this is okay.

Filed bug 663789 with Mozilla. Let's see what they think.

We have a fix ready, still pending review. However, it does work and repairs TED and other affected sites.

Going with our fix.