The following testcase crashes on mozilla-central revision bc8c1eb0f2ba (run with --fuzzing-safe): setObjectMetadataCallback(Date.prototype.toLocaleString); foo();
Brian, can you look into this? It's an infinite recursion with changing stacks, therefore it's not possible to provide a fitting signature.
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: http://hg.mozilla.org/mozilla-central/rev/be1399f8f973 user: Brian Hackett date: Thu May 30 17:37:22 2013 -0600 summary: Bug 850026 - Allow metadata objects to be associated with JS objects, and add a hook for attaching metadata to newly created objects, r=luke. This iteration took 1.922 seconds to run.
Whiteboard: [jsbugmon:update] → [jsbugmon:update,ignore]
JSBugMon: The testcase found in this bug no longer reproduces (tried revision 8648aa476eef).
Whiteboard: [jsbugmon:update,ignore] → [jsbugmon:bisectfix]
Whiteboard: [jsbugmon:bisectfix] → [jsbugmon:]
JSBugMon: Fix Bisection requested, failed due to error (try manually).
autoBisect shows this is probably related to the following changeset: The first good revision is: changeset: http://hg.mozilla.org/mozilla-central/rev/a90070c1243c user: Jim Blandy date: Thu Nov 21 13:25:15 2013 -0800 summary: Bug 637572: Have cloned JSScripts refer to their ScriptSourceObjects via a CCW, not by copying them r=sfink Jim, is bug 637572 a possible fix?
Flags: needinfo?(bhackett1024) → needinfo?(jimb)
I'd be really surprised if that changeset fixed this.
I was half-wrong: the fix for bug 637572 does happen to conceal this bug, but not fix it. However, the bug is not important to content, as it depends on the object metadata callback being used to call JS, which is never the way we'll want to use it. The test case uses TestingFunctions.cpp 'setObjectMetadataCallback' to register a JS function, Date.prototype.toLocaleString, to be called to produce a metadata object to be included in new objects' shapes. As it happens, that function is both 1) lazy, and 2) self-hosted, meaning that it needs to be cloned into the calling compartment, and compiled. Pre-637572, cloning a function allocated a fresh ScriptSourceObject - which then attempted to re-invoke the object metadata callback... Nothing in that call cycle ever checks the recursion depth.
Brian, can you check comment 7? Is this still a problem?
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 950118
You need to log in before you can comment on or make changes to this bug.