I've added an ugly unit test to a branch on my GitHub to illustrate:
https://github.com/capnproto/capnproto/compare/master...Zentren:capnproto:membrane_issue?expand=1#diff-49ad79a4fffcbe88fcd8681ec67d49f5f6e5fc9010961c1b10ef1b462f0e957eR477
Note line 477 in *c++/src/capnp/membrane-test.c++* where I'd expect the
request to have been cancelled as per membrane policy *onRevoked()* docs
("all outstanding calls cancelled"). Looking at the behavior, it seems like
chained promises in the request are not cancelled as part of this (only the
initial *call(CallContext)* IF we have not yet entered its body).
Thanks,
Rowan Reeve
On Wednesday, March 15, 2023 at 3:42:39 PM UTC+2 Rowan Reeve wrote:
> Hi Kenton,
>
> I am encountering a problem where capabilities acting as views over some
> resources are intermittently causing segfaults. The capability is wrapped
> using *capnp::membrane* given a membrane policy where the promise
> returned by *onRevoked* can be rejected on-demand via a synchronous
> reject function (a kj::PromiseFulfillerPair is used to do this).
>
> The resources may be destroyed together at any time, whereby the membrane
> managing the capabilities accessing the resource states is revoked.
> However, this does not seem to be an instantaneous operation (presumably
> due to revocation being managed by a promise), and I have encountered the
> following issue as a result:
>
> Unresolved requests made before the membrane policy has been revoked and
> where the resource has since been destroyed are not cancelled but will
> rather resolve, accessing invalid memory.
>
> The workaround I have found to address this issue is to add a flag and a
> *kj::Canceller* to the capability implementations whereby new requests
> are rejected if the flag is set, and in addition when the flag is first
> set, the canceler cancels all returned promises in cases where a chained
> promise was returned rather than *kj::READY_NOW*. However, this is very
> ugly and necessitates keeping around references to the capability
> implementations before they are converted to *::Client* objects (so that
> we can set that flag). I'm thinking that surely there has to be a better
> way I have not considered.
>
> Do you have any thoughts on a better solution to this problem? If needed,
> I can try create a minimal reproducible example to illustrate.
>
> In case it matters, OS is Ubuntu 20.04 and capnp version is 8.0.0, both
> currently contained by my production environment.
>
> Thank you for your time,
>
> Rowan Reeve
>
--
You received this message because you are subscribed to the Google Groups
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/capnproto/2d126940-b82e-4ef8-9f41-304d8a23c97cn%40googlegroups.com.
