These crashes started with the 2013-11-15-03-02-03-mozilla-central nightly, so they're probably our fault. But all the (5-6) crash reports I look at listed the firebug@software.joehewitt.com extension (various versions) -- so that's also involved, at least as a trigger. Some examples of crashes with the above-mentioned m-c nightly: bp-6d8945b7-c050-400d-9556-a43952131121 bp-bce43a05-9819-4913-91c4-c586b2131116 bp-9c78da14-a76b-4a8a-b03c-9b7b82131115 Though these happen on Windows, there are more of them on OS X (various versions) and Linux -- enough to make them the #2 Mac and Linux topcrasher on the trunk (28 branch).

https://crash-stats.mozilla.com/query/?product=Firefox&version=ALL%3AALL&range_value=4&range_unit=weeks&date=11%2F21%2F2013+16%3A00%3A00&query_search=signature&query_type=contains&query=Scriptability&reason=&release_channels=&build_id=&process_type=any&hang_type=any#

Implied regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7b014f0f3b03&tochange=b2fab608772f

I suspect one of the patches for bug 840488 is the trigger here.

All these crashes are null deferences which happen here: https://hg.mozilla.org/mozilla-central/annotate/c7cbfa315d46/js/xpconnect/src/XPCJSRuntime.cpp#l442 I suspect 'prin' is null.

Looks like the self-hosting global (with its null principal) is finding its way into XPConnect again...

I think a proper fix for this has to consist of either eagerly initializing all builtins or giving the self-hosting global a principal. The latter would be more fundamental, as the former "just" excludes a large batch of possible situations in which getSelfHostedFunction can be called. Not also that, currently, maybeWrappedSelfHostedFunction is the issue, as it (or, rather, GetUnclonedValue) pushes an AutoCompartment. It's perfectly possible for this to happen with lazily-cloned functions, too, however: The function would just have to be invoked while the exception is still on the stack. If the self-hosting global had a principal, all of this wouldn't really matter. bholley, is it possible to give the self-hosting global a principal?

(In reply to Till Schneidereit [:till] from comment #7) > bholley, is it possible to give the self-hosting global a principal? No, because the whole self-hosting model was explicitly designed without consideration for the browser security model. There's no principal we could give it that provides the required semantics. Unless we really want to go back to the drawing board here, the JS engine needs to do a perfect job of hiding the existence of this global from XPConnect. Currently this happens with a lot of explicit |if (isSelfHostingGlobal)| checks. So we could add more of those, or think of something more robust.

Till, can you own this or find an owner?

This should be fixed by bug 911400.

Tracking for now, but we'd probably untrack once we were on Beta (if unresolved) since few Release users would be impacted.

I got today the following crash https://crash-stats.mozilla.com/report/index/794aa854-899c-4c9f-bc59-ecb882131214

FWIW, I can reproduce it using the FBTest extension (for automated test) and Aurora. Steps to reproduce: 1. Install the build of Firebug 1.12.5 (https://addons.mozilla.org/fr/firefox/addon/firebug ) on Firefox Aurora 2. Install FBTest (attached) on the same profile 3. Restart 4. Open FBTest (Shift-T) 5. Run console/testErrors.js |=> Firefox crashes Note that the crash does not occur either in Beta or Nightly. I have bisected a bit and found that the patch that fixes that crash in Nightly is in these commits: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b1e5ade62913&tochange=862cb6a1cc88 My Configuration: Linux Debian Sid, Firefox Aurora, Firebug 1.12.5 Florent

For STR of comment 13

(In reply to fayolle-florent from comment #13) > I have bisected a bit and found that the patch that fixes that crash in > Nightly is in these commits: > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=b1e5ade62913&tochange=862cb6a1cc88 Ok, sounds like this was fixed by bug 911400 then, as expected.

This has dropped to #159 on Aurora with only 10 reports in the last week. Marking this verified based on volume.