Description of problem: /usr/bin/free shows wrong byte count (mega- and kilobytes are correct) Version-Release number of selected component (if applicable): procps-3.2.8-33.el6.x86_64 How reproducible: free -b (bytes) shows more used memory than the total $ /usr/bin/free -b total used free shared buffers cached Mem: 1672607334 3589210112 1313686323 707506176 118784000 1448566784 -/+ buffers/cache: 2021859328 1470421401 Swap: 4227854336 0 4227854336 3'589'210'112 is bigger than 1'672'607'334 (the total is wrong: the machine has 16GB of RAM and not less than 2) Using -m (megabytes), -k (kilobytes) or -g (gigabytes) produces the expected result $ /usr/bin/free -k total used free shared buffers cached Mem: 16334056 3507132 12826924 690924 116168 1414664 -/+ buffers/cache: 1976300 14357756 Swap: 4128764 0 4128764 or $ /usr/bin/free -m total used free shared buffers cached Mem: 15951 3424 12526 674 113 1381 -/+ buffers/cache: 1929 14021 Swap: 4031 0 4031 or $ /usr/bin/free -g total used free shared buffers cached Mem: 15 3 12 0 0 1 -/+ buffers/cache: 1 13 Swap: 3 0 3 Steps to Reproduce: 1. execute /usr/bin/free -b Actual results: Wrong total count (1'672'607'334) Expected results: Exact total count Additional info:
It's not that one value is higher than the other - in fact values in bytes are just truncated to the first 10 digits! This is a regression causing incorrect data to be displayed. Here's my box with 20 GB of SWAP: procps-3.2.8-30.el6: # free -m total used free shared buffers cached Mem: 7852 2311 5541 8 144 938 -/+ buffers/cache: 1228 6623 Swap: 19999 0 19999 # free -b total used free shared buffers cached Mem: 8234053632 2448404480 5785649152 8908800 151695360 983752704 -/+ buffers/cache: 1312956416 6921097216 Swap: 20971515904 0 20971515904 procps-3.2.8-33.el6: # free -m total used free shared buffers cached Mem: 7852 2347 5505 8 144 935 -/+ buffers/cache: 1268 6584 Swap: 19999 0 19999 # free -b total used free shared buffers cached Mem: 8234053632 2460778496 5773275136 8908800 151068672 980430848 -/+ buffers/cache: 1329278976 6904774656 Swap: 2097151590 0 2097151590 Compare the numbers of total SWAP - hopefully the issue is obvious to spot.
Hello guys. I reproduced the issue here. Thanks for the report. Regards, Jaromir.
In fact all values are truncated to the first 10 digits, doesn't matter what unit is chosen. I tried that with very high values and even values in kilobytes were truncated.
The thing is that values longer than 10 digits break the layout and there's no easy way out of this. The unit conversion function that was introduced with the human readable switch truncates the value to 10 characters in order to preserve the layout. Two possible options how to resolve this issue exist. We could add the '+' sign as the last character in order to tell the user, that the value is longer than the column width. Another option would be to break the layout (like it was in the past) and make the output not very well readable.
I would break the layout but this is just my opinion. In any case we could also drop the -b option (since the original values are read from /proc/meminfo in KB)
(In reply to Matteo Corti from comment #6) > I would break the layout but this is just my opinion. Well. Even when it looks ugly, I admit it's probably a better solution, since some users might use the output of 'free' for scripting. With the added '+' sign they would end up with incorrect information and that would be a regression as well. Moreover, the second option is an easyfix/oneliner... --------------------- diff --git a/procps-3.2.8-free-human-readable.patch b/procps-3.2.8-free-human-readable.patch index 1b3cd40..bfd5d63 100644 --- a/procps-3.2.8-free-human-readable.patch +++ b/procps-3.2.8-free-human-readable.patch @@ -21,7 +21,7 @@ diff -Naur procps-3.2.8.orig/free.c procps-3.2.8/free.c +char *S(unsigned long long X) +{ + const char *unit = "BKMGT"; -+ static char buf[11], buf2[11]; ++ static char buf[41], buf2[11]; + int i; + + if (human_readable) { --------------------- The output buffer just needs to be increased in size. I hope 40 characters is sufficient. > In any case we could also drop the -b option (since the original values are > read from /proc/meminfo in KB) That would be a regression as well. We need to keep all features intact.
I agree, removing the -b option would not be the best option (but we could mention in the man page that the base value is in KB, and that -b will not be preciser). An I also agree on the breaking the formatting, otherwise it will break scripts.
"free" output is actively used for processing with scripts so correctness of data must take precedence over prettyness in my opinion. Removing the -b option will also break existing scripts people might have on their RHEL deployments so it should be retained.
*** Bug 1252323 has been marked as a duplicate of this bug. ***
*** Bug 1253036 has been marked as a duplicate of this bug. ***
Hi, we were hit by that issue as our backup software we use (Arkeia) currently uses the -b option for some calculations. Removing or changing this option would break this. So pleas fix it and don't drop it!
*** Bug 1255194 has been marked as a duplicate of this bug. ***
*** Bug 1266714 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-0904.html