All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: Eric Sunshine <sunshine@sunshineco.com>,
	David Turner <dturner@twopensource.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Git List <git@vger.kernel.org>
Subject: Re: [RFD PATCH 0/3] Free all the memory!
Date: Tue, 17 May 2016 11:16:09 -0700	[thread overview]
Message-ID: <xmqqinycwnx2.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAGZ79kaJoAxqtsTuErQSgJiVeD_vdZ1MQXKr-LTtyro-FbscTQ@mail.gmail.com> (Stefan Beller's message of "Tue, 17 May 2016 10:58:30 -0700")

Stefan Beller <sbeller@google.com> writes:

> So as a developer I wish we would close all leaks that are non-concerning.

Valgrind suppression (and if you use other tools, suppression for
them) sounds like the way to go, I would think.

Reducing false positive is a good goal; it helps to highlight the
real problems.  But we need to find a way to do so without hurting
the use by the end users by making them pay the unnecessary cost to
free() at the end and by cluttering the code with #ifdefs that makes
it easier to introduce subtle bugs.

> David writes:
>> AFAIK, nothing in the "definitely lost" category is fixed by your rev-parse patch.
>>
>> I don't think we care that much about "still reachable" memory -- I only care about lost memory.  I could imagine, I guess, something that happens to save a pointer to a bunch of memory that should be freed, but I don't think that's the common case.
>
> As said above I'd want them to be fixed for me as a developer for
> better automated tooling and detection. (The alternative to fix the automated
> tooling is a no-no for me ;)

Does the word "no-no" mean what you seem to think it means?  It
sounds as if you are saying "fixing tools to reduce false positives
is fundamentally wrong, I refuse to go in that direction".

  reply	other threads:[~2016-05-17 18:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-17  3:22 [RFD PATCH 0/3] Free all the memory! Stefan Beller
2016-05-17  3:22 ` [PATCH 1/3] mv: free memory at the end if desired Stefan Beller
2016-05-17  4:14   ` Torsten Bögershausen
2016-05-17  3:22 ` [PATCH 2/3] pack-redundant: free all memory Stefan Beller
2016-05-17  3:42   ` Eric Sunshine
2016-05-17  3:22 ` [PATCH 3/3] rev-parse: " Stefan Beller
2016-05-17  3:41 ` [RFD PATCH 0/3] Free all the memory! Eric Sunshine
2016-05-17 12:08   ` Eric Wong
2016-05-17 17:58   ` Stefan Beller
2016-05-17 18:16     ` Junio C Hamano [this message]
2016-05-17 18:20       ` Stefan Beller
2016-05-18  7:23     ` Eric Wong
2016-05-18 15:19     ` Ævar Arnfjörð Bjarmason
2016-05-17  5:46 ` David Turner
2016-05-17  9:05 ` Matthieu Moy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqinycwnx2.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=dturner@twopensource.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=sbeller@google.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.