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 capnproto+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/capnproto/2d126940-b82e-4ef8-9f41-304d8a23c97cn%40googlegroups.com.
