RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1246379 - free: values truncated to the column width
Summary: free: values truncated to the column width
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: procps
Version: 6.7
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Ondrej Vasik
QA Contact: Branislav Náter
Petr Bokoc
URL:
Whiteboard:
: 1252323 1253036 1255194 1266714 (view as bug list)
Depends On:
Blocks: 1262819
TreeView+ depends on / blocked
 
Reported: 2015-07-24 07:07 UTC by Matteo Corti
Modified: 2019-08-15 04:57 UTC (History)
22 users (show)

Fixed In Version: procps-3.2.8-34.el6
Doc Type: Bug Fix
Doc Text:
Fixes in *free* output With the introduction of the human readable ("-h") switch in the *free* tool, the layout generator had to be modified to support the new feature. This, however, affected printing of values longer than the column width. The values were truncated to prevent the layout from breaking when the values became longer than the reserved space in the columns. At the same time, the change caused *free* to insert an unwanted space character at the end of each line. Due to these two changes, the output could not be used in custom scripts. With this update, values longer than the column width are no longer truncated, no extra spaces are inserted at line ends, and the output of the *free* tool can now be processed without problems.
Clone Of:
: 1262819 (view as bug list)
Environment:
Last Closed: 2016-05-11 00:28:22 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1586063 0 None None None Never
Red Hat Product Errata RHBA-2016:0904 0 normal SHIPPED_LIVE procps bug fix and enhancement update 2016-05-10 22:51:16 UTC

Description Matteo Corti 2015-07-24 07:07:53 UTC 
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:
Comment 2 Evgheni Dereveanchin 2015-08-02 13:15:19 UTC 
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.
Comment 3 Jaromír Cápík 2015-08-03 11:59:33 UTC 
Hello guys.

I reproduced the issue here. Thanks for the report.

Regards,
Jaromir.
Comment 4 Jaromír Cápík 2015-08-03 12:03:54 UTC 
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.
Comment 5 Jaromír Cápík 2015-08-03 12:12:16 UTC 
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.
Comment 6 Matteo Corti 2015-08-03 12:16:48 UTC 
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)
Comment 7 Jaromír Cápík 2015-08-03 12:52:45 UTC 
(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.
Comment 8 Matteo Corti 2015-08-03 12:58:12 UTC 
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.
Comment 10 Evgheni Dereveanchin 2015-08-04 07:05:48 UTC 
"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.
Comment 12 Jaromír Cápík 2015-08-12 11:55:17 UTC 
*** Bug 1252323 has been marked as a duplicate of this bug. ***
Comment 13 Jaromír Cápík 2015-08-12 19:20:37 UTC 
*** Bug 1253036 has been marked as a duplicate of this bug. ***
Comment 18 Götz Reinicke 2015-08-24 09:25:21 UTC 
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!
Comment 19 Marcel Kolaja 2015-08-24 12:34:58 UTC 
*** Bug 1255194 has been marked as a duplicate of this bug. ***
Comment 28 Jaromír Cápík 2015-09-29 12:51:49 UTC 
*** Bug 1266714 has been marked as a duplicate of this bug. ***
Comment 38 errata-xmlrpc 2016-05-11 00:28:22 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.