[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #5552 [Tor Client]: Reported amount of uploaded data occasionally inflated by several gigabytes
#5552: Reported amount of uploaded data occasionally inflated by several gigabytes
------------------------+---------------------------------------------------
Reporter: fk | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: Tor Client | Version: Tor: 0.2.3.13-alpha
Keywords: | Parent:
Points: | Actualpoints:
------------------------+---------------------------------------------------
Comment(by nickm):
So, the wrap-around issue mentioned in the libevent comment is actually
safe: It's for if the internal num_read or num_written field in openssl
overflows past 4GB. Like, before the call, you have written 2**32 - 100.
Then you write 200 bytes. The new value will be 100. So (100 - (2**32 -
100)) will overflow to 200, which is what we wanted.
rransom is right that we need to track down the root cause here: anything
that can add 4GB to the total-written amount will thereby screw up other
stuff too. One way to do this would be by adding appropriate asserts to
bufferevent_ratelim's bufferevent_decrement_write_buckets function in
ratelim.c, then getting a stack trace once the assertions hit. That would
tell us what exactly is decrementing by the insane value, and maybe give
us a clue on how to fix it.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5552#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs