FS#8725 - pacman reports negative download rate
Attached to Project:
Pacman
Opened by Petr Slansky (psl) - Wednesday, 21 November 2007, 09:12 GMT
Last edited by Dan McGee (toofishes) - Sunday, 24 August 2008, 00:15 GMT
Opened by Petr Slansky (psl) - Wednesday, 21 November 2007, 09:12 GMT
Last edited by Dan McGee (toofishes) - Sunday, 24 August 2008, 00:15 GMT
|
Details
Description: pacman reports negative download rate
Additional info: * package version(s) * config and/or log files etc. Notice that download rate reported is negatove, like -265.1K/s; notice huge number of hours, 1193048; this download took less than a minute in the real... Non initialised variable?? Steps to reproduce: $ sudo pacman -Syu :: Synchronizing package databases... core is up to date extra 315.4K -265.1K/s 1193046:28:15 [#####################] 100% community 328.2K -461.1K/s 1193046:28:15 [#####################] 100% :: Starting full system upgrade... local database is up to date $ pacman --version .--. Pacman v3.0.6 - libalpm v1.0.0 / _.-' .-. .-. .-. Copyright (C) 2002-2007 Judd Vinet <jvinet@zeroflux.org> \ '-. '-' '-' '-' '--' $ date Tue Nov 20 13:47:18 CET 2007 |
This task depends upon
Closed by Dan McGee (toofishes)
Sunday, 24 August 2008, 00:15 GMT
Reason for closing: Fixed
Additional comments about closing: Commit e760c4f4784c7e7b59717cd10c56dac04f175b73
Sunday, 24 August 2008, 00:15 GMT
Reason for closing: Fixed
Additional comments about closing: Commit e760c4f4784c7e7b59717cd10c56dac04f175b73
$ date
Wed Nov 21 10:20:54 CET 2007
NTP server is used to synchronize time at my machine, for some reason it didn't updated time correctly and I missed it. I noticed only negative download rate in pacman report... It is possible that NTP system was broken during huge package update yesterday (serious core update).
Taking a quick look at the code, i don't see any uninitialized variables. If anything this is some kind of weird overflow error... Note that 1193046 is much larger than the largest unsigned int value of 65535.
From your notice it looks as my timer was going backwards; is it possible? Timer running in oposite direction will explain behaviour I observed...
(the culprit is likely ust.size during the while loop of the download)
The problem happens with at least one of the french mirrors.
I enabled libdownload debug and verbose mode (in pacman), and installed libdownload with debug enabled too.
Then I ran pacman -Syy, with just the core repo enabled.
With the mir1 french server, all is fine.
With the mir2 french server, it breaks.
And secondly, there can be all kind of scenarios depending on which file is downloaded. It is really odd.
Sometimes, there is just one progress bar, with unkown length (sync of core)
Some other times, the progress bar is split in two, both with unknown lengh (sync of community)
Other times, only one progress bar with known length (sync of extra)
Other times, the first progress bar with unknown length, the second with known (download of wireshark).
The funniest thing is that this looks totally random, but it is not. It is 100% reproducible, as can be seen in the logs I attached. First instance normal, second with verbose libdownload. Maybe it just depends on the size of the file downloaded, I don't know.
And finally, it looks like wget and curl are not able to get the content length either.
If the issue is some kind of weird incompatibilities between some weird http proxies and some weird ftp servers, then this is not our problem, so let's just close this bug.
Just one thing, I was not sure about the value of file_total in this case. I just checked <= 0. But after testing, the value is -1.
And it is documented in man libdownload as well :
"If the size could not be obtained from the server, the size field is set to -1."
So I will update my patch with a stricter test.