assert in trunk 10169 64bit build

[GoogleCodeExporter]

I get the assert TORRENT_ASSERT(s>=0) in:

sliding_average::add_sample(int s)

called from:

peer_connection::start_receive_piece()
..
int rtt = int(total_milliseconds(time_now_hires() - i->request_time));
m_rtt.add_sample(rtt);
..
Looks like i->request_time is zero in case it asserts.

This did not assert in 32bit builds so far.

MassaRoddel

Original issue reported on code.google.com by webmas...@massaroddel.de on 1 Aug 2014 at 8:36

[GoogleCodeExporter]

if request_time was zero, I don't see how subtracting it from time_now_hires() 
could ever become negative. Could it be wrapping the 32 bit int perhaps?

Also though, I wouldn't expect request_time to ever be zero.

Since switching to boost.chrono for time, the min_time() is the smallest 
negative number instead of 0, which causes overflows if a timestamp initialized 
to that is used. I've fixed all the ones I've run into though. Is that involved 
here you think?

Original comment by arvid.no...@gmail.com on 1 Aug 2014 at 3:45

[GoogleCodeExporter]

total_milliseconds returned a value greater than 32Bit because (i guess) 
time_now_hires() was already greater then 32Bit. And so cutting it down to int 
could result in a positive or (my case) negative int.

Original comment by webmas...@massaroddel.de on 1 Aug 2014 at 4:34

[GoogleCodeExporter]

here is an example for a normal value from my 32Bit system. These time values 
seem always to be bigger than 32bit (on windows)

i->request_time = 0x000000f05bce5253

Original comment by webmas...@massaroddel.de on 1 Aug 2014 at 4:47

[GoogleCodeExporter]

Fixed in [10173].

Original comment by arvid.no...@gmail.com on 2 Aug 2014 at 6:10

• Changed state: Fixed