[Bug libstdc++/66339] g++ 5.1.0 Generates memory leak

[frankhb1989 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339

--- Comment #12 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #10)
> This behaviour is by design and is not a bug. Valgrind no longer shows the
> allocation as reachable. Other tools might still show the memory as unfreed,
> but it's still not a bug.

Clarification of "by design" is good. Better put some note elsewhere, maybe. 


(In reply to Jonathan Wakely from comment #11)
> (In reply to frankhb1989 from comment #9)
> > Following your narrow definition of "leak", it implies that any system using
> > GC could never leak. That's absurd.
> 
> Wikipedia: "a memory leak is a type of resource leak that occurs when a
> computer program incorrectly manages memory allocations in such a way that
> memory which is no longer needed is not released."
> 
> This memory is still needed up until exit.
> 
> Google: "a failure in a program to release discarded memory, causing
> impaired performance or failure."
> 
> This is not discarded memory, and does not impair performance or cause
> failure.
> 
> MSDN: "When an application dynamically allocates memory, and does not free
> that memory when it is finished using it, that program has a memory leak."
> 
> The memory is in use right until exit, so the application hasn't finished
> using it.
> 
>  
> > A leak of resource may occur when the client (either the code of the
> > application or the underlying runtime responsible to deal with the allocated
> > resource) has lost the control of the lifetime of that resource.
> 
> The runtime hasn't lost control of it.
> 
> > If that
> > resource is not needed and there is no other way to transfer the ownership,
> > it is leaked.
> 
> It's still needed.
> 
> > Still reachable memory can be leaked, depends on the
> > intention. Sometimes the leak detector has no clue to figure out whether the
> > memory should be still here or not, but we humans have, though it may be
> > arguable.
> > 
> > The situation necessitating "exit()" to cleanup almost always meets the
> > condition of leak above. This is feasible only when the users can rely on
> > the fact that the hosting environment will cleanup the (already leaked)
> > resources of that program (likely in some magical ways unrelated to the
> > program itself). This is not portable in general.
> 
> We're not talking about arbitrary resources in the general case, we're
> talking about heap memory in the GNU C++ runtime. That memory is freed on
> exit. If you want to waffle about it further please take it somewhere else.
> 
> 
> 
>  (And abuse of exit() will
> > easily cause other problems.) I don't see "most" programs do that seriously
> > because it is not easy to guarantee the behavior predictable.


I'm not sure if you are talking about the general cases here.

In general, attributing leaks to unreachable resources despite the need, is
nonsense; as my previous reply.

For this issue, you are correct that GNU C++ runtime does not "cause impaired
performance or failure".

I just know the memory "is still needed" (by the runtime) by design. Fine.

It can still be a QoI issue for user programs because when don't need it (as
the original case), though.