Closed GoogleCodeExporter closed 9 years ago
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).
Original comment by classi...@floodgap.com
on 9 Jun 2011 at 1:34
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.
Original comment by classi...@floodgap.com
on 9 Jun 2011 at 1:11
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
Original comment by classi...@floodgap.com
on 9 Jun 2011 at 1:50
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.
Original comment by classi...@floodgap.com
on 10 Jun 2011 at 3:45
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
Original comment by classi...@floodgap.com
on 10 Jun 2011 at 1:06
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.
Original comment by classi...@floodgap.com
on 12 Jun 2011 at 9:49
Attachments:
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.
Original comment by classi...@floodgap.com
on 13 Jun 2011 at 3:16
Filed bug 663789 with Mozilla. Let's see what they think.
Original comment by classi...@floodgap.com
on 13 Jun 2011 at 12:51
We have a fix ready, still pending review. However, it does work and repairs
TED and other affected sites.
Original comment by classi...@floodgap.com
on 15 Jun 2011 at 2:12
Going with our fix.
Original comment by classi...@floodgap.com
on 16 Jun 2011 at 12:34
Original issue reported on code.google.com by
jamie.r....@gmail.com
on 8 Jun 2011 at 9:56Attachments: