Maybe -A should include JS_CHECK_RECURSION checks in addition to heap allocations. Or maybe there should be a debug function for "please make the Nth next JS_CHECK_RECURSION fail artificially".

I do have a proof-of-concept implementation for the JS shell that uses a second parameter "-R" to make recursion checks fail. The main question is, do we want to fail exactly one (the "R-th") check to fail, or all subsequent checks as well? I currently have experiments running with both settings to see if we can find bugs with this.

I'm not sure. Another possibility is to lower the stack limit to whatever point first fails the check, so only deeper calls fail after that point.

(In reply to Jesse Ruderman from comment #2) > I'm not sure. Another possibility is to lower the stack limit to whatever > point first fails the check, so only deeper calls fail after that point. That sounds like the most realistic way to simulate real behavior, and it's certainly easy to implement. But we probably have to divide the available address space into chunks to that we reduce step by step.

See also bug 735081.

I had an idea for this. We mostly want to make stack checks more deterministic. This is hard because the actual size of a stack frame is non-deterministic. However, we could have a shadow stack of deterministic size that we could use for the stack checks in --enable-more-determinism builds. We would replace the usual stack checks with an auto class, like this: AutoStackCheck asc(cx); if (asc.overflow()) return false; In normal builds, this would do the usual stack check business. In special builds, it would increment a counter when pushing the class and decrement when popping. The overflow check would check if the counter is greater than some fixed value that would be controllable. The nice thing about this is that it gives us the same "cascading failure" behavior that the real stack checks have. That is, if one check failed, then several nearby checks are likely to fail as well, since the stack is still big. What do you guys think?

Great idea!

+1, awesome idea

Could we prevent these bugs rather than (or in addition to) getting better at detecting them? See bug 813646.