public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Derrick Stolee <stolee@gmail•com>
To: Stefan Beller <sbeller@google•com>, Jeff King <peff@peff•net>
Cc: "Martin Ågren" <martin.agren@gmail•com>,
	gitgitgadget@gmail•com, git <git@vger•kernel.org>,
	"Junio C Hamano" <gitster@pobox•com>,
	"Derrick Stolee" <dstolee@microsoft•com>
Subject: Re: [PATCH 1/2] commit-graph: clean up leaked memory during write
Date: Wed, 3 Oct 2018 08:04:30 -0400	[thread overview]
Message-ID: <1686b309-e0af-5518-0fa5-4635b2f481b9@gmail.com> (raw)
In-Reply-To: <CAGZ79kaatUeHEGnW9HXv7Xgsj1Sf_M6hcgQ_5oVAOM85rqn34Q@mail.gmail.com>

On 10/2/2018 6:44 PM, Stefan Beller wrote:
>> My preference is to avoid them in the name of simplicity. If you're
>> using "make SANITIZE=leak test" to check for leaks, it will skip these
>> cases. If you're using valgrind, I think these may be reported as
>> "reachable". But that number already isn't useful for finding real
>> leaks, because it includes cases like the "foo" above as well as
>> program-lifetime globals.
>>
>> The only argument (IMHO) for such an UNLEAK() is that it annotates the
>> location for when somebody later changes the function to "return -1"
>> instead of dying. But if we are going to do such annotation, we may as
>> well actually call free(), which is what the "return" version will
>> ultimately have to do.
> Heh, that was part of my reasoning why we'd want to have *something*.
>
>> I'd actually be _more_ favorable to calling free() instead of UNLEAK()
>> there, but I'm still mildly negative, just because it may go stale (and
>> our leak-checking wouldn't usefully notice these cases). Anybody
>> converting that die() to a return needs to re-analyze the function for
>> what might need to be released (and that includes non-memory bits like
>> descriptors, too).
> Sounds reasonable, so then the consensus (between Martin, you and me)
> is to drop the UNLEAK.
Thanks for the discussion here. I'll drop the UNLEAK for now and think 
about how to remove the die() calls from commit-graph.c in a later series.

Thanks,
-Stolee

  reply	other threads:[~2018-10-03 12:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-02 14:58 [PATCH 0/2] Clean up leaks in commit-graph.c Derrick Stolee via GitGitGadget
2018-10-02 14:58 ` [PATCH 1/2] commit-graph: clean up leaked memory during write Derrick Stolee via GitGitGadget
2018-10-02 15:40   ` Martin Ågren
2018-10-02 17:59     ` Stefan Beller
2018-10-02 19:08       ` Martin Ågren
2018-10-02 19:44         ` Stefan Beller
2018-10-02 22:34           ` Jeff King
2018-10-02 22:44             ` Stefan Beller
2018-10-03 12:04               ` Derrick Stolee [this message]
2018-10-03 15:36                 ` [PATCH 0/2] commit-graph: more leak fixes Martin Ågren
2018-10-03 15:36                   ` [PATCH 1/2] commit-graph: free `struct packed_git` after closing it Martin Ågren
2018-10-03 15:36                   ` [PATCH 2/2] builtin/commit-graph.c: UNLEAK variables Martin Ågren
2018-10-03 16:19                   ` [PATCH 0/2] commit-graph: more leak fixes Derrick Stolee
2018-10-03 16:24                     ` Martin Ågren
2018-10-02 22:37       ` [PATCH 1/2] commit-graph: clean up leaked memory during write Jeff King
2018-10-02 14:58 ` [PATCH 2/2] commit-graph: reduce initial oid allocation Derrick Stolee via GitGitGadget
2018-10-03 17:12 ` [PATCH v2 0/3] Clean up leaks in commit-graph.c Derrick Stolee via GitGitGadget
2018-10-03 17:12   ` [PATCH v2 1/3] commit-graph: clean up leaked memory during write Derrick Stolee via GitGitGadget
2018-10-03 17:12   ` [PATCH v2 2/3] builtin/commit-graph.c: UNLEAK variables Martin Ågren via GitGitGadget
2018-10-03 17:12   ` [PATCH v2 3/3] commit-graph: reduce initial oid allocation Derrick Stolee via GitGitGadget

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=1686b309-e0af-5518-0fa5-4635b2f481b9@gmail.com \
    --to=stolee@gmail$(echo .)com \
    --cc=dstolee@microsoft$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitgitgadget@gmail$(echo .)com \
    --cc=gitster@pobox$(echo .)com \
    --cc=martin.agren@gmail$(echo .)com \
    --cc=peff@peff$(echo .)net \
    --cc=sbeller@google$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox