Bugzilla@Mozilla – Bug 501270
Assertion failure: !fp->fun || !(fp->fun->flags & JSFUN_HEAVYWEIGHT) || fp->callobj
Last modified: 2009-09-18 14:12:05 PDT
Summon comment box
browser only, js1_5/extensions/regress-361964.js on mac and nt at least. security sensitive until I can find the regressor. Assertion failure: !fp->fun || !(fp->fun->flags & JSFUN_HEAVYWEIGHT) || fp->callobj, at /work/mozilla/builds/1.9.0/mozilla/js/src/jsinterp.c:663
bug 460882 regressed this.
ping?
bz: i'm only seeing this on 1.9.0. Is there an underlying bug on 1.9.1/1.9.2?
Blake says no.
Created attachment 386149 [details] [review] Proposed fix As far as I can tell, the only reason this doesn't bite on trunk is that we're a lot smarter about what we call "heavyweight" and what forces a call object. Also, document.title is quickstubbed on trunk and 1.9.1, so we end up computing this with a frame pushed on top of the pseudo-frame created by the watchpoint code. I think this patch is generally correct, so I'll attach a trunk version right away.
Created attachment 386154 [details] [review] For trunk
Comment on attachment 386149 [details] [review] Proposed fix Looks right. /be
Comment on attachment 386154 [details] [review] For trunk I diff'ed the patches to see the changes from 1.9.0 -- looks good again. /be
Comment on attachment 386149 [details] [review] Proposed fix This is needed to fix a regression from a security fix. It's preventing bc from running the JS testsuite in debug builds.
http://hg.mozilla.org/tracemonkey/rev/02eca43038ef
Comment on attachment 386149 [details] [review] Proposed fix Approved for 1.9.0.12, a=dveditz for release-drivers bc: please verify this after Blake lands.
Checking in js/src/jsdbgapi.c; /cvsroot/mozilla/js/src/jsdbgapi.c,v <-- jsdbgapi.c new revision: 3.153; previous revision: 3.152 done
v 1.9.0.12 on mac browser. no assert on 1.9.1-tracemonkey either.
http://hg.mozilla.org/mozilla-central/rev/02eca43038ef
Fixed this in 1.9.0.12, so we should fix it in 1.9.1.1.
Blake: Can you request approval on a patch that applies?
mrbkap says that we can wait until 1.9.1.2 if that's coming in the next few weeks, which it is!
Blake: can you whip us up a mozilla-1.9.1 patch so we can get it landed insteda of rushing at the last minute to get it in?
Comment on attachment 386154 [details] [review] For trunk If this gets approval, please approve the patch in bug 502449 at the same time.
Comment on attachment 386154 [details] [review] For trunk Approved for 1.9.1.2. a=ss for release-drivers Please land on mozilla-1.9.1 and use the ".2-fixed" option of the "status1.9.1" flag.
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/7853bc76a1e3
the referenced test never failed on 1.9.1/1.9.2. it still doesn't.
What is the best/simplest way for QA to verify this for 3.5.2?
(In reply to comment #23) > What is the best/simplest way for QA to verify this for 3.5.2? Compile a js shell and see if the testcase file in comment #0 still asserts.
(In reply to comment #24) > (In reply to comment #23) > > What is the best/simplest way for QA to verify this for 3.5.2? > > Compile a js shell and see if the testcase file in comment #0 still asserts. it never did.
(In reply to comment #25) > (In reply to comment #24) > > (In reply to comment #23) > > > What is the best/simplest way for QA to verify this for 3.5.2? > > > > Compile a js shell and see if the testcase file in comment #0 still asserts. > > it never did. D'oh, sorry, never noticed "browser-only" in comment #0 till now, so I guess you have to compile a debug browser build.
no, actually it never asserted on 1.9.1/1.9.2 only 1.9.0. The underlying bug wasn't exposed by the test case there.
bc: Do you think it safe to mark this bug verified1.9.1 based on comment 27?
nope, otherwise I would have. I don't think it is a problem shipping like this, but what's the point in rubber stamping it other than to clean up a bug query?