overflow issue in Transmission/1.01

[charles]

03:41 < jaits> hi
03:41 < jaits> i cant be asked to register in the forum so i thought i d post it 
               here
03:41 < jaits> &peer_id=-TR1010-pwb1nelxkwhn
               &port=51413
               &uploaded=845708079 
               &downloaded=36471044486
               &corrupt=158253056 
               &left=18446744073709518848
               &compact=1
               &numwant=0
               &key=jw7nw47kxh 
               &supportcrypto=1
               &requirecrypto=0
               &event=stopped HTTP/1.1
03:41 < jaits> theres an overflow issue in Transmission/1.01 (4635)
03:42 < jaits> torrent size: 65.94 GB (70,799,478,784)
03:42 < jaits> amount left reported: 8,388,608.00 TB
03:42 < jaits> which is impossible
03:42 < jaits> its not my client
03:42 < jaits> i m a tracker owner... so maybe the dude has recompiled and 
               caused this, but i doubt that tbh
03:42 < jaits> he's a gd member
03:53 < wereHamster> the value is uint64_t, that's enough to hold the 65GB.. 
                     you'll have to wait
03:55 < jaits> yea i guessed its an overflow :p
03:55 < jaits> anyhow.. i suggest u fix it soon...
03:55 < jaits> i wont ban this version yet since we only have 2 torrents that 
               can cause this overflow... but if it starts happening all the 
               time i will have no choice
03:55 < jaits> it triggers my anti-cheating scripts
03:56 < jaits> plz inform whoever needs to be informed
03:56 < jaits> cheers.
03:57 < wereHamster> thanks for the report
03:57 < jaits> np, cu
04:01 < wereHamster> 18446744073709518848 = 0xFFFFFFFFFFFF8000 and 0x8000 = 
                     32768, probably a one too much cp->completeHave += 
                     blockSize;
04:01 < wereHamster> would be my naive guess
04:03 < wereHamster> what about an assert(cp->tor->info.totalSize >= 
                     cp->completeHave) in tr_cpLeftUntilComplete() ?

[charles]

To restate wereHamster -- the variables in question are uint64_t...

18446744073709551615 is uint64_max 18446744073709518848 is the "left" sent to the tracker (uint64_max - left == 32767

cp->completeHave must've underflowed...

[charles]

trunk: r4840 1.0x: r4841