STR: - open url (logged in) expected: the different modul options being presented actual: "Loading..." is shown setting javascript.options.jit.content to "false" fixes this. TM works: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090513 Minefield/3.6a1pre ID:20090513221509 http://hg.mozilla.org/tracemonkey/rev/22ef5690efbf fails: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090513 Minefield/3.6a1pre ID:20090513231923 http://hg.mozilla.org/tracemonkey/rev/010768e6119c => range: http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=22ef5690efbf&tochange=010768e6119c 1.9.1 branch works: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090515 Shiretoko/3.5b5pre ID:20090515045515 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a6445e2e8691 fails: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090517 Shiretoko/3.5b5pre ID:20090517065612 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/43de7d34998a => range: http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=a6445e2e8691&tochange=43de7d34998a Trunk works: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090514 Minefield/3.6a1pre ID:20090514015635 http://hg.mozilla.org/mozilla-central/rev/ec0e6d5f5bc7 fails: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090514 Minefield/3.6a1pre ID:20090514030309 http://hg.mozilla.org/mozilla-central/rev/a1fc27041e53 => range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ec0e6d5f5bc7&tochange=a1fc27041e53

arrgg, forgot to add the error console output: Error: Node cannot be inserted at the specified point in the hierarchy = NS_ERROR_DOM_HIERARCHY_REQUEST_ERR Source file: http://s.ytimg.com/yt/js/account_all-vfl94379.js Line: 1018

Is it for certain that the patch for bug 492914 caused this? /be

well, it's weird that a one-liner could cause this, but i just double-checked the range: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090513 Minefield/3.6a1pre ID:20090513172444 http://hg.mozilla.org/tracemonkey/rev/0827b97fb89b Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090513 Minefield/3.6a1pre ID:20090513221509 http://hg.mozilla.org/tracemonkey/rev/22ef5690efbf do both work Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090513 Minefield/3.6a1pre ID:20090513231923 http://hg.mozilla.org/tracemonkey/rev/010768e6119c first to fail, and the next one too: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090514 Minefield/3.6a1pre ID:20090514031914 http://hg.mozilla.org/tracemonkey/rev/010768e6119c you can check yourself: http://hourly-archive.localgho.st/hourly-archive2/tracemonkey-win32/ 1242278109-20090513221509-22ef5690efbf-firefox-3.6a1pre.en-US.win32.zip 1242281963-20090513231923-010768e6119c-firefox-3.6a1pre.en-US.win32.zip both lead to the TM pushlog range mentioned in comment 0 where the fix checkin for bug 492914 is the only one.

The patch might be a 1-liner but its definitively not a trivial change. I have no doubt it can cause the regression. Thanks a lot for the bisecting this.

Fun, any hope of a reduction? /be

Want to get this into tm, so we can try it on top of the not-backed-out regressing patch (for bug 492914). PND_FORWARD (tested by isForward, which you can see is used only in assertion -- but PND_FORWARD is also tested using two-bits-one-test magic in NoteLValue) may be ripe for removal. The code right after the if-then removed by this patch uses source coordinates, which in a basic block are sufficient and (evidently) more reliable. If this doesn't fix the problem, I'll have to target NoteLValue. Has anyone confirmed that the backout of the patch for bug 492914 from the 1.9.1 branch fixed this bug's symptoms? /be

for Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b5pre) Gecko/20090517 Shiretoko/3.5b5pre ID:20090517212951 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0d35fc939701 it is working again.

If this doesn't fix things, then something was relying on the bogus PND_FORWARD flag contagion that could happen before I fixed bug 492914, that something being a latent bug we don't know about yet. I hope that's not the scenario. My build is going and I'll be testing shortly, would like to get it into tm for wider testing. /be

Is it also possible that we're tracing more now and that we're hitting some correctness bug in the tracer?

Can't burn callee object ref on trace, guardCallee uses underlying function ptr, not one-of-N callees. /be

Fixes the bug. Working on a shell testcase. /be

Exposed by patch for bug 492914 but the regressing patch was the original -- the big one for bug 452498. /be

Fixed in tm: http://hg.mozilla.org/tracemonkey/rev/aac8141341bf /be

Could reduce more to make it look less like the original source, but it seems helpful to keep some of that resemblance. /be

this caused Bug 493760