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.

Description of problem:

In __malloc_stats(), mi.arena (defined as size_t) is cast to unsigned int, causing incorrect values to be displayed for > 4GB. 

   fprintf (stderr, "system bytes     = %10u\n", (unsigned int) mi.arena);
   fprintf (stderr, "in use bytes     = %10u\n", (unsigned int) mi.uordblks);

Version-Release number of selected component (if applicable):
Linux XXXXXX 2.6.32-573.12.1.el6.x86_64 #1 SMP Mon Nov 23 12:55:32 EST 2015 x86_64 x86_64 x86_64 GNU/Linux

__________________________________________________
LSB Version:    :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: RedHatEnterpriseServer
Description:    Red Hat Enterprise Linux Server release 6.7 (Santiago)
Release:        6.7
Codename:       Santiago


Glib Version::
===============
glibc-2.12-1.166.el6_7.3.x86_64
glibc-headers-2.12-1.166.el6_7.3.x86_64
glibc-devel-2.12-1.166.el6_7.3.x86_64
glibc-2.12-1.166.el6_7.3.i686
avahi-glib-0.6.25-15.el6.x86_64
glib2-2.28.8-4.el6.x86_64
dbus-glib-0.86-6.el6_4.x86_64
glibc-common-2.12-1.166.el6_7.3.x86_64

The above problem also exists in glib 2.25.

Red Hat Enterprise Linux 6 is a production stage 3 OS and the kind of change you are suggesting is not suitable for this release. Instead I'm moving this bug to RHEL 7 where the problem is still present.

The public API which is relevant is malloc_stats(), and the result is cast to (int) because it's using mallinfo() internally and it only returns int sized results.

DJ Delorie (on the glibc team) is looking at mallinfo() (https://sourceware.org/ml/libc-alpha/2016-10/msg00142.html) to make it saturing. In the case of mallinfo we have a published API which only has type 'int' so we can't do any real fixes for mallinfo(). However, we might be able to get 'unsigned int' out of the interface e.g. up to 4GB (right now signed int is 2GB).

An even better solution for malloc_stats() exists, and that is to use size_t internally and print the values as correctly as possible, avoiding the use of mallinfo() internally.

I have posted a patch on https://sourceware.org/bugzilla/show_bug.cgi?id=21556#c2 that fixes malloc_stats() without changing the `mallinfo()` API, as Carlos O'Donell said.

This issue is going to be tracked upstream in the following bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=21556

We are going to mark this issue CLOSED/USPTREAM.

When we work out the upstream solution we will reconsider this for inclusion in RHEL.