Closed Bug 779858 Opened 10 years ago Closed 10 years ago

new Error(...) is crashing in a very uncommon scenario

Categories

(Core :: XPConnect, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: gkrizsanits, Unassigned)

Details

This bug was reported by Alex here: 
https://bugzilla.mozilla.org/show_bug.cgi?id=777705#c10


Gabor, with this try server build, I get some crashes.
That ends up being one of my most complex bug recipe I cooked up so far!!
The list of ingredient is quite impressive:
 - Two sandboxes:
   - One with just system principal 
    (No idea why it works if you execute its content in scratchpad)
   - Another one using expanded principal, with just one origin
 - Use loadSubScript to load the crashing code
 - Use new Error() which trigger the crash

Here is a scratchpad crashing code:
  // Here window is the toplevel xul one, so equivalent to give systemPrincipal
  var s1 = Components.utils.Sandbox(window);
  Components.utils.evalInSandbox("new " + function () {
    // If you take this 3 lines and put them directly in scratchpad, it works?!
    Components.utils.import("resource://gre/modules/Services.jsm");
    // Use expanded principals here
    var s2 = Components.utils.Sandbox(["http://mozilla.org"]);
    // You need to create a file somewhere and reference it here
    // test.js just contains: new Error('foo');
    Services.scriptloader.loadSubScript("file:///C:/test.js", s2);
  }, s1);
seems like this was a false alarm and this only happens with a patch that has not yet landed. So this should be closed.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.