search

zenhack / irc-idler

IRC idler app for sandstorm
GNU General Public License v3.0
4 stars 2 forks source link

Unable to store ipNetwork cap. #8

Open zenhack opened 8 years ago

zenhack commented 8 years ago

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.

zenhack commented 8 years ago

Worth noting, if the capability is actually stored, we may also be leaking on every restart.

paulproteus commented 8 years ago

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!

zenhack commented 8 years ago

@paulproteus, testing with commit 0594dc9fac5fda26e503c39060adce54126646b6, 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.

zenhack commented 8 years ago

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?

zombiezen commented 8 years ago

Struct() will return after the connection receives a Return message for the answer. It has no bearing on a promised capability's resolution. In the code you linked me, you could just as easily use portPromise.Connect(...).Upstream() and have correct results, since you don't need to wait for the struct to do promise pipelining.

Perhaps we need to revisit zombiezen/go-capnproto2#2? I've cleaned up most of the internals of the rpc package now, so I could give it a whirl.

zenhack commented 8 years ago

@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.

zenhack commented 7 years ago

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.