mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.4 2022-01-13T13:12:29Z 2022-01-13T13:12:29Z Ian Jackson iwj@torproject.org 2022-01-13T13:12:29Z urn:sha1:9b723cba53852ecd3505c0cabc42ca3b5d31ad34 2021-12-26T01:22:38Z Neel Chauhan neel@neelc.org 2021-12-26T01:22:38Z urn:sha1:383843f0d7d7c0b1f9b75c115fb4bf4a09496dfa 2021-12-20T15:56:24Z Nick Mathewson nickm@torproject.org 2021-12-20T15:56:24Z urn:sha1:6303a71d58849d0bdbd21022eda6fb079ae151e5 These will require thought; should we ignore them, act on them, or continue to treat them as internal errors? 2021-11-29T16:10:51Z Nick Mathewson nickm@torproject.org 2021-11-29T16:08:34Z urn:sha1:efe165acf3e7467ef31ebe6765c710d4d8c9322b This test seems unreliable on CI: we've got to disable them for now so that we have a working CI system. The CI failure is #238; the ticket to repair them is #244. 2021-11-25T13:20:37Z Daniel Eades danieleades@hotmail.com 2021-11-25T13:14:05Z urn:sha1:db16d13df4779ac61005050dfe5ce05e3d5a1b5d 2021-11-23T22:40:13Z Nick Mathewson nickm@torproject.org 2021-11-23T22:40:13Z urn:sha1:54de7f5cfd82eb04e1e119d1734eee2d6ee1176d 2021-11-18T16:06:53Z eta tor@eta.st 2021-11-18T15:40:18Z urn:sha1:075e663dcd740727ea6832581a38dc6ab0a36d53 The `bad_extend_*` failures were caused by bad test code in `bad_extend_test_impl` that used `futures::join!`; this meant that the reactor could receive the `Extended2` cell before it actually got the `ExtendNtor` request, which caused it to get (quite rightly) confused and close the circuit. Spawning a background thread which has a short delay before sending the `Extended2` cell seems to have alleviated this problem. `new_circ_create_failure` is similar; I think the reactor was getting dropped before it had a chance to flush out its `CreateFast` cell properly, because it had already gotten the result back (since the test code sends it indiscriminately). This was "fixed" in much the same manner as the other test: making it wait a bit before sending the result cell back. There seem to be other tests that use `futures::join!` (like `begindir`?), and use similarly erroneous patterns; I haven't gotten any to fail reliably enough to be able to debug them, though. 2021-11-15T17:57:01Z Nick Mathewson nickm@torproject.org 2021-11-15T17:55:08Z urn:sha1:f92ad644c90480cd6ea738201119ce1e9fd40d8e Closes #222. 2021-11-13T16:22:08Z Nick Mathewson nickm@torproject.org 2021-11-13T16:22:08Z urn:sha1:c6d188869f18c3446f800fe93c37356790187ca7 2021-11-12T15:04:27Z eta tor@eta.st 2021-11-11T17:44:50Z urn:sha1:c559754116678866eabe525f5b189b50cc78b5cc Previously, the reactor would use an `UnboundedSender` to send things to the `RawCellStream`, in order that the reactor wouldn't block if you failed to read from the latter. This is bad, though, since it means people can just run us out of memory by sending lots of things. To fix this, we make the new `StreamReader` type (which does the reading parts from `RawCellStream`) keep track of the stream's receive window and issue SENDMEs once *it* has consumed enough data to require it, thus meaning that we shouldn't get sent enough data to fill the channel between reactor and `StreamReader` (and, if we do, that's someone trying to flood us, and we abort the circuit). As hinted to above, the `RawCellStream` was removed and its reading functionalities replaced by `StreamReader`; its writing functionalities are handled by `StreamTarget` anyway, so we just give out one of those for the write end. This now means we don't need any mutexes! note: this commit introduces a known issue, arti#230