Re: [PATCH 3/5] submodule: helper to run foreach in parallel
- From
Stefan Beller <sbeller@google.com>
- Date
- Aug 26, 2015, 17:21 UTC
- Message-ID
- <CAGZ79kaWh5F_d9TGHFe-fAd5arFicaAVcmYnWnAS2Wn1PoGMzg@mail.gmail.com>
- In-Reply-To
- <20150826170647.GA1870@sigill.intra.peff.net>
On Wed, Aug 26, 2015 at 10:06 AM, Jeff King <peff@peff.net> wrote:
Show 30 quoted lines
> On Tue, Aug 25, 2015 at 10:28:24AM -0700, Stefan Beller wrote:
>
>> +int module_foreach_parallel(int argc, const char **argv, const char *prefix)
>> +{
>> [...]
>> + for (i = 0; i < ce_used; i++) {
>> + const struct submodule *sub;
>> + const struct cache_entry *ce = ce_entries[i];
>> + struct submodule_args *args = malloc(sizeof(*args));
>> +
>> + if (ce_stage(ce))
>> + args->sha1 = xstrdup(sha1_to_hex(null_sha1));
>> + else
>> + args->sha1 = xstrdup(sha1_to_hex(ce->sha1));
>> +
>> + strbuf_reset(&sb);
>> + strbuf_addf(&sb, "%s/.git", ce->name);
>> + if (!file_exists(sb.buf))
>> + continue;
>
> "args" and "args->sha1" go out of scope and leak here.
>
>> + args->name = sub->name;
>> + args->toplevel = xstrdup(xgetcwd());
>
> Another xgetcwd leak. :) I think this one can just drop the xstrdup.
>
> (Both of these were spotted by Coverity. I know you have played with it
> a little, so if you are actually reading the emails it sends, I'll stop
> relaying them).Fixing those memleaks was the first thing I did this morning. :)
And yeah I do pay attention to these emails. (I maintain the automatic testing every other day, so there is that.)
> > -Peff