-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tst.postmortem_jsstack.js occasionally fails spuriously #38
Comments
It seems this is definitely what's happening. I collected the output of We can see that when the test fails, the following optimizations are traced:
and there's no trace for any deoptimization of those functions. On the other hand, the output for when the test passes does not contain any trace of optimizations for any of the functions that this test wants to see on the stack. V8 provides an intrinsic named With the following changes to
I'm able to consistently get that test to pass when running it with So here's the implementation I suggest in order to fix that test:
How does that sound? |
I actually got confused, this is not how I have a preference for the former, but I'm not sure if that's in scope of |
catest is a general-purpose test-runner, and we shouldn't have local changes to it. We could create the idea of a catest configuration file that determines what commands are run based on file extension and use that in this project to change how it runs .js files. I'm not sure whether we want to be testing with optimizations off or not. If mdb_v8 does the wrong thing with optimizations, that's pretty unfortunate. On the other hand, if that's only because this sequence of calls is so simple, and it's not that realistic a scenario, then maybe the test is just too simple. In that case, we could make it more realistic (in a way that wouldn't be inlined) or just make the proposed change (on the assumption that we're testing the more realistic case by doing that). |
While testing the fix for #32, I ran into an intermittent failure that I don't believe is a result of that change. I tested each combination of (v0.10.40, v0.12.7, v4.0.0) x (ia32, amd64). In two full runs of the test suite in each configuration, I saw this issue twice: once on v.10.40 ia32, and once on v4.0.0 amd64.
The failure looks like this:
and the core file looks like this:
I suspect (but haven't proved) that V8 is inlining some function calls.
The text was updated successfully, but these errors were encountered: