Bug 348978 - Valgrind reports unfreed memory for trivial C++ programs
Summary: Valgrind reports unfreed memory for trivial C++ programs
Status: RESOLVED DUPLICATE of bug 345307
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: 3.10.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
Depends on:
Reported: 2015-06-10 13:50 UTC by invalid
Modified: 2015-09-21 21:05 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description invalid 2015-06-10 13:50:41 UTC
Valgrind reports unfreed memory for all C++-programs that are linked against the standard library. I believe this issue was introduced after I updated from glibc 2.21-3 to 2.21-4 (I tested this scenario on my laptop that still has 2.21-2 - no issue there). I originally reported the issue as a problem with the glibc-Package in the Arch-Linux-Bugtracker (https://bugs.archlinux.org/task/45051), but I was told to report it here.
I could not reproduce the same issue for C programs.

Reproducible: Always

Steps to Reproduce:
1. Write trivial C++ program (for example: empty main function, just with a "return 0")
2. Compile with g++ main.cpp
3. valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./a.out

Actual Results:  
==2694== Memcheck, a memory error detector
==2694== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==2694== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==2694== Command: ./cpp
==2694== HEAP SUMMARY:
==2694==     in use at exit: 72,704 bytes in 1 blocks
==2694==   total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
==2694== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==2694==    at 0x4C29F90: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2694==    by 0x4EC01EF: pool (eh_alloc.cc:117)
==2694==    by 0x4EC01EF: __static_initialization_and_destruction_0 (eh_alloc.cc:244)
==2694==    by 0x4EC01EF: _GLOBAL__sub_I_eh_alloc.cc (eh_alloc.cc:307)
==2694==    by 0x400F0E9: call_init.part.0 (in /usr/lib/ld-2.21.so)
==2694==    by 0x400F1FA: _dl_init (in /usr/lib/ld-2.21.so)
==2694==    by 0x4000DB9: ??? (in /usr/lib/ld-2.21.so)
==2694== LEAK SUMMARY:
==2694==    definitely lost: 0 bytes in 0 blocks
==2694==    indirectly lost: 0 bytes in 0 blocks
==2694==      possibly lost: 0 bytes in 0 blocks
==2694==    still reachable: 72,704 bytes in 1 blocks
==2694==         suppressed: 0 bytes in 0 blocks
==2694== For counts of detected and suppressed errors, rerun with: -v
==2694== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Expected Results:  
It should not report any leaks with a program like this

* package version(s) (Arch Linux)
glibc 2.21-4
gcc 5.1.0-4
valgrind 3.10.1-2
Comment 1 Florian Krohm 2015-09-21 21:05:27 UTC

*** This bug has been marked as a duplicate of bug 345307 ***