You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm adding more tests to exercise the full set of states (to be named gc-kernel-orphan.test), which are currently failing for both syscall.abandonExports() and terminateVat(), happening either before or after an importing vat uses syscall.dropImports() to drop down to the merely-recognizable state. My new test is not exercising the upgrade/abandon-non-durables case.
have it make some merely-virtual (non-durable) objects
export that object to a second vat, which adds it to a WeakStore, and then drops the Representative
wait for the GC dropImports to make it back to the first vat, leaving the object in the "recognized but unreachable" state
now upgrade the first vat
the kernel ought to retire the merely-virtual object on behalf of the upgraded vat
the second vat should receive a dispatch.retireImports
The new test wants to go into gc-kernel-orphan.test, but it can't use the existing framework because that framework uses createTestVat, and we can't upgrade such vats, and we need to upgrade the vat so we can trigger the abandon-non-durable code in processVatUpgrade.
So we'll need a new framework that creates a pair of static vats or something. The createTestVat approach was convenient because we can snoop on the deliveries and syscalls very directly (no bundles or extra Compartments involved). So the alternative will probably involve vatPowers.testLog.
The text was updated successfully, but these errors were encountered:
Originally posted by @warner in #7212 (comment)
We need a test that will:
dropImports
to make it back to the first vat, leaving the object in the "recognized but unreachable" statedispatch.retireImports
The new test wants to go into
gc-kernel-orphan.test
, but it can't use the existing framework because that framework usescreateTestVat
, and we can't upgrade such vats, and we need to upgrade the vat so we can trigger the abandon-non-durable code inprocessVatUpgrade
.So we'll need a new framework that creates a pair of static vats or something. The
createTestVat
approach was convenient because we can snoop on the deliveries and syscalls very directly (no bundles or extra Compartments involved). So the alternative will probably involvevatPowers.testLog
.The text was updated successfully, but these errors were encountered: