Jeff King writes:
> Overall I suspect that running our cmd_*() functions multiple times in a
> single process is already going to cause chaos, because they often are
> touching static globals, etc. So it's probably not that big a deal in
> practice to add one more variable to the list, and declar
Jeff King writes:
> On Mon, Aug 28, 2017 at 10:52:51AM -0700, Stefan Beller wrote:
>
>> >> I'm curious, too. I don't think the valgrind setup in our test suite is
>> >> great for finding leaks right now.
>>
>> This discussion comes up every once in a while,
>> the last time I was involved in thi
On Tue, Aug 29, 2017 at 05:48:09PM -0400, Jeff King wrote:
> On Tue, Aug 29, 2017 at 09:22:08PM +0200, Martin Ågren wrote:
>
> > One take-away for me from this thread is that memory-leak-plugging seems
> > to be appreciated, i.e., it's not just an academic problem. I think I'll
> > look into it s
On Tue, Aug 29, 2017 at 09:22:08PM +0200, Martin Ågren wrote:
> One take-away for me from this thread is that memory-leak-plugging seems
> to be appreciated, i.e., it's not just an academic problem. I think I'll
> look into it some more, i.e., slowly pursue option 2. :-) That might help
> give som
On 29 August 2017 at 20:53, Jeff King wrote:
> On Tue, Aug 29, 2017 at 06:51:52PM +0100, Lars Schneider wrote:
>> What if we run a few selected tests with valgrind and count all files that
>> valgrind mentions (a single leak has multiple file mentions because of
>> the stack trace and other leak i
On Tue, Aug 29, 2017 at 06:51:52PM +0100, Lars Schneider wrote:
> I set $TOOL_OPTIONS in valgrind.sh: to
> '--leak-check=full --errors-for-leak-kinds=definite'
>
> ... but I also had to adjust t/test-lib-functions.sh:test_create_repo
> as I ran into the error "cannot run git init -- have you bui
> On 28 Aug 2017, at 06:11, Martin Ågren wrote:
>
> On 28 August 2017 at 01:23, Jeff King wrote:
>> On Sun, Aug 27, 2017 at 10:04:55PM +0200, Lars Schneider wrote:
>>
>>> I did run all tests under valgrind using "make valgrind" and I found
>>> the following files with potential issues:
>>>
>>
On Mon, Aug 28, 2017 at 10:52:51AM -0700, Stefan Beller wrote:
> >> I'm curious, too. I don't think the valgrind setup in our test suite is
> >> great for finding leaks right now.
>
> This discussion comes up every once in a while,
> the last time I was involved in this discussion I proposed
> to
>>> No mention of "pkt-line.c". Did you run Git with valgrind on one of
>>> your repositories to find it?
>>
>> I'm curious, too. I don't think the valgrind setup in our test suite is
>> great for finding leaks right now.
>
This discussion comes up every once in a while,
the last time I was involv
On 28 August 2017 at 01:23, Jeff King wrote:
> On Sun, Aug 27, 2017 at 10:04:55PM +0200, Lars Schneider wrote:
>
>> I did run all tests under valgrind using "make valgrind" and I found
>> the following files with potential issues:
>>
>> cat valgrind.out | perl -nE 'say /^==.+\((.+)\:.+\)$/' | sort
On Sun, Aug 27, 2017 at 10:04:55PM +0200, Lars Schneider wrote:
> I did run all tests under valgrind using "make valgrind" and I found
> the following files with potential issues:
>
> cat valgrind.out | perl -nE 'say /^==.+\((.+)\:.+\)$/' | sort | uniq -c
> 7102
>2 clone.c
> 33 common-main.
> On 27 Aug 2017, at 21:09, Martin Ågren wrote:
>
> On 27 August 2017 at 20:21, Lars Schneider wrote:
>>
>>> On 27 Aug 2017, at 09:37, Martin Ågren wrote:
>>>
>>> The static-ness was silently dropped in commit 70428d1a5 ("pkt-line: add
>>> packet_write_fmt_gently()", 2016-10-16). As a result
On Sun, Aug 27, 2017 at 09:09:15PM +0200, Martin Ågren wrote:
> On 27 August 2017 at 20:21, Lars Schneider wrote:
> >
> >> On 27 Aug 2017, at 09:37, Martin Ågren wrote:
> >>
> >> The static-ness was silently dropped in commit 70428d1a5 ("pkt-line: add
> >> packet_write_fmt_gently()", 2016-10-16)
On 27 August 2017 at 20:21, Lars Schneider wrote:
>
>> On 27 Aug 2017, at 09:37, Martin Ågren wrote:
>>
>> The static-ness was silently dropped in commit 70428d1a5 ("pkt-line: add
>> packet_write_fmt_gently()", 2016-10-16). As a result, for each call to
>> packet_write_fmt_1, we allocate and leak
On Sun, Aug 27, 2017 at 11:41:52AM -0400, Jeff King wrote:
> Ouch. So this means that git since v2.11 is basically leaking every
> non-byte pack sent by upload-pack (so all of the ref advertisement and
> want/have negotiation).
Determined experimentally that the answer is: yes.
The increase in r
> On 27 Aug 2017, at 09:37, Martin Ågren wrote:
>
> The static-ness was silently dropped in commit 70428d1a5 ("pkt-line: add
> packet_write_fmt_gently()", 2016-10-16). As a result, for each call to
> packet_write_fmt_1, we allocate and leak a buffer.
Oh :-( Thanks for detecting and fixing the l
On Sun, Aug 27, 2017 at 09:37:32AM +0200, Martin Ågren wrote:
> The static-ness was silently dropped in commit 70428d1a5 ("pkt-line: add
> packet_write_fmt_gently()", 2016-10-16). As a result, for each call to
> packet_write_fmt_1, we allocate and leak a buffer.
>
> We could keep the strbuf non-s
The static-ness was silently dropped in commit 70428d1a5 ("pkt-line: add
packet_write_fmt_gently()", 2016-10-16). As a result, for each call to
packet_write_fmt_1, we allocate and leak a buffer.
We could keep the strbuf non-static and instead make sure we always
release it before returning (but no
18 matches
Mail list logo
