I'm getting this crash while testing, I guess it might be related to bug 459869. It's also crashing in 1.9.1 builds. Note that this is with a normal computer. http://crash-stats.mozilla.com/report/index/c774e274-27c7-4354-80be-9a4302090318?p=1 0 js3250.dll js_FillPropertyCache js/src/jsinterp.cpp:144

Ok, I finally have a (sort of) testcase. Unfortunately, it can take a very long time to crash, like 30 minutes or so. When trying to minimize, I opened 5 tabs of the file named 'parentframe.htm' and then waited until it crashed.

Rob? This a blocker?

Interestingly, I got this to iloop on MacOS inside js_SearchScope. Somehow scope->hashShift is -33, which seems bad. I'll keep looking.

Who's going to take this? Let's get an owner ASAP.

With the test case I got a crash after running a browser for about hour or so. It it at a different place but I suspect it is just another face of the same underling bug.

I can't get this to crash anymore.

I bet Igor fixed this by reordering fill vs. resolve/getter/setter call. /be

been running with this for a long time, and I'm running 5 tabs worth of it right now. don't see this function in top crashes either.

I should have updated the info on this bug long time ago: This bug can be just a dup of 487204. I have found that bug when trying to reduce the test case from the comment 1 and with that bug fixed the test case stopped crashing. But then the bug 487846 is also a result of checking the code when analyzing this bug and in principle could be triggered with the test case. So I just record the dependencies and this fixed as aresult of fixing these two bugs.

This testcase does not appear to affect the 1.9.0 branch. Maybe I didn't wait long enough, but I'm getting lots of errors that I don't get in Shiretoko

Yes, this doesn't affect the 1.9.0 branch, afaict. At least I couldn't get it to crash on that branch.

fixed before we branched