[Webkit-unassigned] [Bug 69583] Structure does not reset m_previous when pinning the property map

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Oct 6 20:16:35 PDT 2011


--- Comment #9 from Filip Pizlo <fpizlo at apple.com>  2011-10-06 20:16:35 PST ---
(In reply to comment #8)
> Since we know this caused assertion failures (bug 69555), it seems like it should be possible to write a regression test for this fix.

I would have hoped so!

This is the second bug I've fixed in our structure property map code. The last time, I tried really hard to do every possible permutation of structure transitions from JS code, and could not trigger a failure.  Not this one, and not the previous one, either.

I haven't tried to write a test case for this fail, because of the disappointment I had the last time around: https://bugs.webkit.org/show_bug.cgi?id=69102

The problem is that normal JS code execution calls materializePropertyMap() only in a few cases, and never in cases where the state of Structure* would have already been messed up (because of this bug and the other previously fixed one), and so never sees the fail.  We do however call materializePropertyMap() from the tiered compilation infrastructure.  But tiered compilation kicks in when a collection of heuristics decide that it's profitable to do so.  That ends up being stochastic.  And then it only calls materializePropertyMap() if its profiling (which is also stochastic) tells it that it's profitable.  So for sufficiently complex code, you get calls to materializePropertyMap() at random times that don't fit the pattern that would be encountered from vanilla JS code.

Forcing it to happen at exactly the right time so that materializePropertyMap() encounters the failing case, by trying to hand-write a JS test case, is rough.

What would be good, is to write unit tests for JSC::Structure.  I'm not sure if that's feasible at this time, since the unit test would have to try pretty hard to bring up a full JS environment with global datas, objects, a GC heap, etc., and then perform evil structure transitions whilst repeatedly calling materializePropertyMap().  But maybe if we're doing that then we might as well resort to doing tests using JS fuzzers.

But in my past experience, the best test case for these chaotic interactions in a VM is just the application (in this case, the website) that caused them.

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list