Recursion limit differs between TM and interpreter, take 3

RESOLVED FIXED

Status

()

--
minor
RESOLVED FIXED
9 years ago
6 years ago

People

(Reporter: jruderman, Assigned: dvander)

Tracking

(Blocks: 2 bugs, {testcase})

Trunk
x86
Mac OS X
testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
var x = 0;
try {
  (function r(d) { x++; if (d > 0) r(d - 1); })(4500);
} catch(e) { }
print(x);

Interpreter: 3000
TM: 3001

Previously fixed bugs: bug 520498, bug 522136.

This isn't a serious bug on its own, but it interferes with jsfunfuzz's ability to test for other TM/interpreter inconsistency bugs, which often *are* serious.
(Reporter)

Updated

9 years ago
Blocks: 465479

Updated

9 years ago
Assignee: general → dvander

Comment 1

9 years ago
dvander's patch for bug 565373 broke this. it also broke the trace-test for bug 522136, which seems to be testing the same issue. not sure why it is still there, keeping the tree orange.
Created attachment 446070 [details] [diff] [review]
fix

This test case is silly, as is the requirement that recursion limits be precisely identical between every mode of execution. Maintaining this invariant is tricky in JM and will break there under certain circumstances. jsfunfuzz should learn how to work around it.

In the meantime, this should patch won't execute traces if they could bump the inline call count past the interpreter's limit.
Attachment #446070 - Flags: review?(lw)

Updated

9 years ago
Attachment #446070 - Flags: review?(lw) → review+
http://hg.mozilla.org/tracemonkey/rev/49da92b4c672

sorry for orange.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-tracemonkey
Filter on qa-project-auto-change:

Bug in removed tracer code, setting in-testsuite- flag.
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.