-
Notifications
You must be signed in to change notification settings - Fork 212
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
flake in SwingSet gc test #9392
Comments
Ok, so I think this is another case of V8 being not consistent about GC handling, which we've usually dealt with by forcing the test to use an XS/xsnap worker instead of a Node.js/V8/"local" worker. This This depends upon all of:
I think step 4 is sometimes failing under V8. When this same problem has caused other flaky tests, we've generally not been able to reproduce it locally, for some reason it only seems to fail in CI. The #3482 issue was discovered while investigating an XS bug (#3406), and once that issue was fixed, we found the remaining problem. At first I thought it was a second XS bug, but further experimentation showed it happened on both XS and V8, exonerating XS, and driving the investigation into liveslots. That's why the test I added was using So I think the solution is to flip that switch to make it only use XS, where GC behaves more consistently than under Node. I'll make a PR. |
This "forward to fake zoe" in gc-vat.test was added to demonstrate a fix for #3482, in which liveslots was mishandling an intermediate promise by retaining it forever, which made us retain objects that appear in eventual-send results forever. This problem was discovered while investigating an unrelated XS engine bug (#3406), so "is this specific to a single engine?" was on our mind, and I wasn't sure that we were dealing with two independent bugs until I wrote the test and showed that it failed on both V8 and XS. So the test was originally written with a commented-out `managerType:` option to make it easy to switch back and forth between `local` and `xs-worker`. That switch was left in the `local` state, probably because it's slightly faster. What we've learned is that V8 sometimes holds on to objects despite a forced GC pass (see #5575 and #3240), and somehow it only seems to fail in CI runs (and only for people other than me). Our usual response is to make the test use XS instead of V8, either by setting `creationOptions.managerType: 'xs-worker'` on the individual vat, or by setting `defaultManagerType: 'xs-worker'` to set it for all vats. This PR uses the first approach, changing just the one vat being exercised (which should be marginally cheaper than making all vats use XS). closes #9392
@turadg not sure how frequently this was happening, but try including this patch in the failing PRs, and see if it helps. It should be harmless to land on trunk, and follows a pattern we've used before with other test flakes, so we could also just land it and then allow your PRs to go on top of it. |
) This "forward to fake zoe" in gc-vat.test was added to demonstrate a fix for #3482, in which liveslots was mishandling an intermediate promise by retaining it forever, which made us retain objects that appear in eventual-send results forever. This problem was discovered while investigating an unrelated XS engine bug (#3406), so "is this specific to a single engine?" was on our mind, and I wasn't sure that we were dealing with two independent bugs until I wrote the test and showed that it failed on both V8 and XS. So the test was originally written with a commented-out `managerType:` option to make it easy to switch back and forth between `local` and `xs-worker`. That switch was left in the `local` state, probably because it's slightly faster. What we've learned is that V8 sometimes holds on to objects despite a forced GC pass (see #5575 and #3240), and somehow it only seems to fail in CI runs (and only for people other than me). Our usual response is to make the test use XS instead of V8, either by setting `creationOptions.managerType: 'xs-worker'` on the individual vat, or by setting `defaultManagerType: 'xs-worker'` to set it for all vats. This PR uses the first approach, changing just the one vat being exercised (which should be marginally cheaper than making all vats use XS). closes #9392
Some of these tests were updated in 9d3c496, but it looks like we didn't switch to using an xs worker for that bootstrap vat. Changing the following line to
Will open a PR |
Will address new issue in #10071 |
Hit today, Is this only in Node? Do we expect GC in Node to be deterministic? If not, could we test GC only in XS? |
What is the Problem Being Solved?
Description of the Design
Security Considerations
Scaling Considerations
Test Plan
Upgrade Considerations
The text was updated successfully, but these errors were encountered: