Assertion failure: JSVAL_IS_NULL(vp[0]) || (!JSVAL_IS_PRIMITIVE(vp[0]) && OBJ_IS_ARRAY(cx, JSVAL_TO_OBJECT(vp[0]))), at /Users/jruderman/central/js/src/jsbuiltins.cpp:287 in js_String_p_match I hit this once and was not able to reproduce. I have a stack trace, but I don't know how helpful it is. I was using mozilla-central and had jit enabled for content. Brendan is thinking of adding some extra printf stuff in the case where that assertion fails, so we'll at least know what type the thing is when the assertion fails.

I hit this again today, this time in String_p_match (not js_String_p_match).

Loading http://www.brf.com.sg/ifos2/index.jsp triggers this assertion failure.

And so does loading http://www.likecool.com/.

Here's a js shell testcase, reduced from the URL in comment 2. var a, z; for (a = 0; a < 8; a++) {} "x".toLowerCase(); for (z = 0; z < 4; z++) void (['0','0','0'][z].match(/0/) ? 1 : 2); js -j b8.js Assertion failure: JSVAL_IS_NULL(vp[0]) || (!JSVAL_IS_PRIMITIVE(vp[0]) && OBJ_IS_ARRAY(cx, JSVAL_TO_OBJECT(vp[0]))), at jsstr.cpp:1448

The assert is a bit bogus. We should add a static assert on the jsval trickery and fix the assert.

Note, i get a lot of crashes on the automated TopSite Testrun (see Bug 463377) today and this Assertion before the Crash.

Also a problem on Windows. I was running into this fatal assertion on http://buxbb.com/index.php?showtopic=62736 during the Windows Topsite Run using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;rv:1.9.1b2pre) Gecko/20081111 Minefield/3.1b2pre

(In reply to comment #5) > The assert is a bit bogus. We should add a static assert on the jsval trickery > and fix the assert. When I remove the assertion outright, I hit one of waldo's assertions trying to pop a totally bogus boolean in the interpreter. I don't have time to debug further, though.

I just hit this browsing cnn.com.

Jason, need help with this?

Sorry, didn't realize this was assigned to me. It's a red herring that the loop will read past the end of the array; we actually assert before it gets there. A few printfs produce: str_match at pc=0x30d3a0 returning: jsval 14 (0xe) = true str_match at pc=0x30d3a0 returning: jsval 14 (0xe) = true String_p_match at pc=0x30d3a0 returning: jsval 14 (0xe) = true Assertion failure: JSVAL_IS_BOOLEAN(v), at ../jsbool.cpp:180 What String_p_match is actually returning there is JSVAL_TO_OBJECT(JSVAL_TRUE), or 0x8. The JITted code depends on String_p_match returning a booloid; we got JSVAL_TRUE when recording, so the emitted guard tests for the exact value 1. Instead it gets 8, so we bogusly side exit. Then when we restore the interpreter stack, the value we put at the top of the stack is BOOLEAN_TO_JSVAL(0x8), or 0x46. This bogus jsval triggers the later assert mentioned in comment 8.

Instead of returning 8 on success in this case, return a pointer to an arbitrary object. I can't convince myself that this would be safe without the TempValueRooter. I am imagining a case where no one is on trace, and the branch callback is called from js_ExecuteRegExp.

I am about to split regexp such that we collect results into an array and then trigger the lambda function from a follow-up loop. Would this eliminate the need for the rooter?

Bug 466351 and bug 468184 are about other web sites hitting this assertion.

This patch has review -- what's keeping it from landing?

Sorry, guys. http://hg.mozilla.org/tracemonkey/rev/08c43641ab86 Andreas, re comment 13: Even without the branch callback, js_ExecuteRegExp can overwrite *rval and then allocate strings, which could trigger GC.

test included in js1_8_1/trace/trace-test.js http://hg.mozilla.org/mozilla-central/rev/8f967a7729e2

v 1.9.1, 1.9.2