Jesse Ruderman Reporter
	Description • 14 years ago

(function too_much_recursion(i){print(i);{too_much_recursion(i+1)}})(0)

interp: 2999
-j:     2999
-m:     3000

I could tell my fuzzer to ignore differences when it's intentionally doing too-much-recursion, but then I could miss some bugs.  Also, the fuzzer often unintentionally causes too-much-recursion, and it's hard to detect those cases.

	Sean Stangl [:sstangl]
	Comment 1 • 14 years ago

To free some of my memory:

Related to this, we can recurse beyond JS_MAX_INLINE_COUNT -- JaegerShot() sets the VMFrame.inlineCallCount to 0, disregarding the inlineCallCount seen by the interpreter.

So if we write a function that recursively has an unjittable function calling a jittable function calling the unjittable function, the inlineCallCount keeps getting reset, so we keep recursing until we run out of stack frames.

	David Anderson [:dvander] - inactive, e-mail if emergency
	Comment 2 • 14 years ago

Jesse, I'm thinking this is WONTFIX. As of bug 586886 recursion limits are now based on stack usage and not call counts. I think this is the right decision for the JIT, but not necessarily the interpreter & tracer.

We could do it in both places to try and maintain some semblance of consistency, but this consistency was a farce to begin with - finicky and unreliable, like checkStats() or timing. Certainly we can no longer have tests that assert the recursion limit precisely matches some given number of calls.

	Jesse Ruderman Reporter
	Comment 3 • 14 years ago

I've modified the fuzzer so it doesn't do output-comparison when it intentionally generates a too-much-recursion function.

Sometimes it accidentally generates a too-much-recursion function.  This is a contrived example, but I'd expect the fuzzer to generate things like it:

var i=0; try { function r() { ++i; r(); } r(); } catch(e) { } print(i);

We'll see how often this happens.

	David Anderson [:dvander] - inactive, e-mail if emergency
	Comment 4 • 14 years ago

Sounds good, thanks for the workaround.

	Jesse Ruderman Reporter
	Comment 6 • 11 years ago

We ultimately went with a more robust workaround in bug 706433: shells compiled with --enable-more-deterministic print a message on stderr when they hit a recursion limit.