-
-
Notifications
You must be signed in to change notification settings - Fork 2
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
Unable to store ipNetwork cap. #8
Comments
Worth noting, if the capability is actually stored, we may also be leaking on every restart. |
What does "using the cap doesn't" work mean precisely? Does it give you an exception? Do RPCs hang forever with no response? Perhaps this is a subtler weirder bug than either you or I guessed! |
...Obviously should never hit master; trying to debug zenhack/irc-idler#8.
@paulproteus, testing with commit 0594dc9, which is right before I disabled the restore (because it wasn't working). From the app's perspective it appears to work, but the irc server never even recieves a connection (I tested this by pointing it at a simple tcp server that does a debugging print when accept() returns). Bits just go into the abyss. Note that this is all being driven by https://github.com/zenhack/go.sandstorm/blob/master/ip/ip.go, which doesn't ever force resolution of the promises. I tried forcing the result of connect() on another branche here: https://github.com/zenhack/go.sandstorm/blob/irc-idler-8-debug/ip/ip.go, but the result is the same. |
To be clear, "forcing" in this context doesn't actaully refer to waiting for a capnp resolve message (go-capnproto2 doesn't do promise resolution yet), and I'm a little fuzzy on exactly what that call to Struct() does in this case, since there's nothing but an interface value to wait for. @zombiezen, what exactly does it do in that case? |
Perhaps we need to revisit capnproto/go-capnp#2? I've cleaned up most of the internals of the rpc package now, so I could give it a whirl. |
@zombiezen, properly fixing that issue might make debugging this kind of thing easier, yeah. I doubt that's actually the problem, since both versions of the code work fine with the newly allocated capability, just not the restored version. My hope with the second version was that I'd get an error sooner (or at all), but no such luck. |
I figured this out while adding this to sandstorm-znc; I was just not setting the label param when calling save. There was even a TODO. D'oh. IRC Idler is officially unmaintained, so I'm not going to bother pushing a fix, but commenting for posterity. |
I'm not 100% sure this is even supposed to be persistent, but there's some disabled code that tries to save the cap to disk and then later restore it. The api.Save() appears to work, as does the restore, but actually using the cap doesn't. not sure what's up.
The text was updated successfully, but these errors were encountered: