This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: Memory leaks in compiler

From: Nicholas Nethercote <njn at csse dot unimelb dot edu dot au>
To: Tom Tromey <tromey at redhat dot com>
Cc: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>, Vincent Lefevre <vincent+gcc at vinc17 dot org>, gcc at gcc dot gnu dot org, Jerry DeLisle <jvdelisle at verizon dot net>
Date: Thu, 17 Jan 2008 16:13:57 +1100 (EST)
Subject: Re: Memory leaks in compiler
References: <4787C3C4.5020909@verizon.net> <20080111203135.GA8113@prunille.vinc17.org> <Pine.GSO.4.58.0801160022270.19987@caipclassic.rutgers.edu> <m37ii9bnn1.fsf@fleche.redhat.com> <000401c85884$227db450$6501a8c0@glap> <m33asxbixb.fsf@fleche.redhat.com>

On Wed, 16 Jan 2008, Tom Tromey wrote:

Kaveh> A valgrind suppression only silences the error for valgrind.  What if
Kaveh> someone uses another memory checking tool?  Better to fix it for real
Kaveh> IMHO.

Add suppressions for all of them.  Any decent memory checker has to
account for the reality that many programs don't bother freeing memory
before exit.

Valgrind (Memcheck) generally only complains about unfreed blocks for which there is no pointer in live data, ie. truly leaked ones. But it's not perfect, there are various ways it can be fooled.

Nick

References:
- Memory leaks in compiler
  - From: Jerry DeLisle
- Re: Memory leaks in compiler
  - From: Vincent Lefevre
- Re: Memory leaks in compiler
  - From: Kaveh R. GHAZI
- Re: Memory leaks in compiler
  - From: Tom Tromey
- Re: Memory leaks in compiler
  - From: Kaveh R. Ghazi
- Re: Memory leaks in compiler
  - From: Tom Tromey

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]