On 25 September 2017 at 18:08, Jeff King wrote:
> On Sun, Sep 24, 2017 at 09:59:28PM +0200, Martin Ågren wrote:
>
>> > I'm not sure of the best way to count things.
>>
>
> But at least on the topic of "how many unique leaks are there", I wrote
> the script below to try to give some basic answers.
On Sun, Sep 24, 2017 at 09:59:28PM +0200, Martin Ågren wrote:
> > Anyway, doing:
> >
> >
> > ASAN_OPTIONS=detect_leaks=1:abort_on_error=0:exitcode=0:log_path=/tmp/lsan/output
> > \
> > make SANITIZE=address,leak test
> >
> > should pass the whole suite and give you a host of files to analyze
On 24 September 2017 at 09:01, Junio C Hamano wrote:
> Martin Ågren writes:
>
>> Since Junio collected my "independent" patches into ma/leakplugs, this
>> is a re-roll of that whole topic. I got the first two patches from
>> Junio's tree. The only difference there is "builtin/" at the very start
On 23 September 2017 at 18:38, Jeff King wrote:
> On Sat, Sep 23, 2017 at 12:13:16PM -0400, Jeff King wrote:
>
>> In theory you should be able to just add "log_path=/tmp/lsan/output" to
>> that, which should put all the logs in a convenient place (and stop the
>> extra output from confusing any te
Martin Ågren writes:
> Since Junio collected my "independent" patches into ma/leakplugs, this
> is a re-roll of that whole topic. I got the first two patches from
> Junio's tree. The only difference there is "builtin/" at the very start
> of the first commit message.
Thanks, all 6 look sensible.
On Sat, Sep 23, 2017 at 12:13:16PM -0400, Jeff King wrote:
> In theory you should be able to just add "log_path=/tmp/lsan/output" to
> that, which should put all the logs in a convenient place (and stop the
> extra output from confusing any tests which capture stderr). But I can't
> seem to get lo
On Sat, Sep 23, 2017 at 11:54:31AM +0200, Martin Ågren wrote:
> Unfortunately, I have not figured out how to get LSan to simply report
> the leaks and continue. Its default behavior is to abort if there are
> leaks. That's useful for finding the first leaking test, but not much
> else. (Later test
On 23 September 2017 at 06:37, Jeff King wrote:
> On Sat, Sep 23, 2017 at 01:34:48AM +0200, Martin Ågren wrote:
>
>> Martin Ågren (6):
>> builtin/commit: fix memory leak in `prepare_index()`
>> commit: fix memory leak in `reduce_heads()`
>> leak_pending: use `object_array_clear()`, not `free
On Sat, Sep 23, 2017 at 01:34:48AM +0200, Martin Ågren wrote:
> Martin Ågren (6):
> builtin/commit: fix memory leak in `prepare_index()`
> commit: fix memory leak in `reduce_heads()`
> leak_pending: use `object_array_clear()`, not `free()`
> object_array: use `object_array_clear()`, not `f
On 20 September 2017 at 22:02, Jeff King wrote:
> On Wed, Sep 20, 2017 at 09:47:24PM +0200, Martin Ågren wrote:
>
>> Instead of conditionally freeing `rev.pending.objects`, just call
>> `object_array_clear()` on `rev.pending`. This means we don't poke as
>> much into the implementation, which is a
10 matches
Mail list logo
