Bug 1267709 - glibc runtime doesn't release all allocated memory before exit
glibc runtime doesn't release all allocated memory before exit
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
22
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Carlos O'Donell
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-30 14:27 EDT by Liviu Vasut
Modified: 2016-11-24 07:12 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-09 22:06:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Liviu Vasut 2015-09-30 14:27:12 EDT
Description of problem:
Program compiled with gcc 5.1.1 is reported by valgrind as having memory leaks

Version-Release number of selected component (if applicable):
g++ (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
valgrind-3.10.1
Linux verne.localdomain 4.1.7-200.fc22.i686+PAE #1 SMP Mon Sep 14 20:36:56 UTC 2015 i686 i686 i386 GNU/Linux

How reproducible:
Always

Steps to Reproduce:
1. execute:
echo "int main(){ return 0; }" | g++ -x c++ - -o problem && valgrind --leak-check=full ./problem

Actual results:
Output of valgrind:
==2023== Memcheck, a memory error detector
==2023== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==2023== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==2023== Command: ./problem
==2023== 
==2023== 
==2023== HEAP SUMMARY:
==2023==     in use at exit: 18,944 bytes in 1 blocks
==2023==   total heap usage: 1 allocs, 0 frees, 18,944 bytes allocated
==2023== 
==2023== LEAK SUMMARY:
==2023==    definitely lost: 0 bytes in 0 blocks
==2023==    indirectly lost: 0 bytes in 0 blocks
==2023==      possibly lost: 0 bytes in 0 blocks
==2023==    still reachable: 18,944 bytes in 1 blocks
==2023==         suppressed: 0 bytes in 0 blocks
==2023== Reachable blocks (those to which a pointer was found) are not shown.
==2023== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==2023== 
==2023== For counts of detected and suppressed errors, rerun with: -v
==2023== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


Expected results:
valgrind should not report any leaks

Additional info:
the same test was run on another two machines, both showing the expected leak free output of valgrind

Versions on:
-machine 2
g++ (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1)
valgrind-3.10.1 --- (this is the same version as the one that reported leaks on the first machine with version 5.1.1 of gcc)
Linux XXX.XX 3.18.5-201.fc21.i686 #1 SMP Mon Feb 2 21:36:12 UTC 2015 i686 i686 i386 GNU/Linux

-machine 3
g++-4.7.real (Debian 4.7.2-5) 4.7.2
valgrind-3.7.0
Linux YYY.YY 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt11-1~bpo70+1 (2015-06-08) x86_64 GNU/Linux
Comment 1 Jakub Jelinek 2015-09-30 14:31:12 EDT
That has nothing to do with gcc, and is really just misunderstanding of what valgrind prints.  Still reachable memory is nothing bad.  And if you use --show-reachable=yes, you'll see that it has been allocated by the dynamic linker.
Comment 2 Liviu Vasut 2015-09-30 14:39:39 EDT
Al right, could you please change the component to the appropriate one then? I'm not sure where this should go...
Comment 3 Liviu Vasut 2015-09-30 14:41:20 EDT
(In reply to Liviu Vasut from comment #2)
> Al right, could you please change the component to the appropriate one then?
> I'm not sure where this should go...

nevermind, I didn't notice the changes. Thanks
Comment 4 Carlos O'Donell 2015-10-09 22:06:53 EDT
We are never going to fix this, and even then we might make that number larger, there are internal glibc buffers which we don't care to free because exit will unmap the memory anyway. Therefore unmapping it by hand will simply slow down exit and add shutdown latency.

Marking as WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.