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
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.
(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
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.
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