You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@gmail.com> on 2010/02/18 01:07:58 UTC
memory leak? ref: merge test 4
I'm running into a problem with merge test 4. Some kind of memory
leak, or other memory double-free or somesuch.
During the 'svn switch', it just seems to head off into la-la land.
Consumes a TON of memory before I kill it off.
Has anybody seen this? Ring any bells?
Thx,
-g
Re: memory leak? ref: merge test 4
Posted by Philip Martin <ph...@wandisco.com>.
Greg Stein <gs...@gmail.com> writes:
> I think the memory usage might actually be our test harness attempting
> to read all of the (stderr) output into memory. Thousands and
> thousands of lines that read:
>
> svn(56985,0xa0634720) malloc: *** error for object 0x817a00: double free
> *** set a breakpoint in malloc_error_break to debug
>
> So maybe svn isn't consuming memory, but is simply generating a
> hojillion of these error lines. I forced an abort/coredump, and found
> this stack:
>
> #0 0x952e329a in write$NOCANCEL$UNIX2003 ()
> #1 0x9538f3ce in malloc_destroy_zone ()
> #2 0x9538e8e3 in malloc_zone_print_ptr_info ()
> #3 0x9538e943 in malloc_printf ()
> #4 0x9538941a in scandir$INODE64 ()
> #5 0x952b3523 in malloc_zone_free ()
> #6 0x952b338d in free ()
> #7 0x004d230c in apr_allocator_destroy (allocator=0x502010) at
> memory/unix/apr_pools.c:134
> #8 0x000101b5 in main (argc=11, argv=0xbffff0ac) at subversion/svn/main.c:2288
I don't see it on Linux (Debian stable) and I've run merge_tests 4
with the svn client running under valgrind.
--
Philip
Re: memory leak? ref: merge test 4
Posted by Greg Stein <gs...@gmail.com>.
This problem was caused by the tweak on the APR 1.3.x branch to put
hash data into a subpool. I've updated my 1.3 installation to tip of
the branch, which backed that change out.
On Sun, Feb 21, 2010 at 21:32, Greg Stein <gs...@gmail.com> wrote:
> Those errors might be from the MacOS C library.
>
> So I looked into this some more. Backdating to r886351 (when we first
> bumped to format 16) would cause the problem to core dump, rather than
> some weird endless hang. Bisecting the changes, I find that r906110 is
> where the code switches from a core dump to a hang. It apparently
> tickles wc_db in a slightly different way, and alters the resulting
> symptom of some underlying double-free or somesuch.
>
> Gotta investigate further. See if I can put in some early checks for
> improper reuse or pool lifetime issues. I think the errors may be
> creeping up around pool-destroy time (and trying to access the wc_db
> during this time, while it is in partial-readiness).
>
> Cheers,
> -g
>
> On Thu, Feb 18, 2010 at 11:13, C. Michael Pilato <cm...@collab.net> wrote:
>> I'm not seeing this problem, but then I don't think I'm setup to generate
>> stderr spam on malloc/free errors (via the likes of "MALLOC_CHECK_=1" in the
>> environment or somesuch).
>>
>> Greg Stein wrote:
>>> I think the memory usage might actually be our test harness attempting
>>> to read all of the (stderr) output into memory. Thousands and
>>> thousands of lines that read:
>>>
>>> svn(56985,0xa0634720) malloc: *** error for object 0x817a00: double free
>>> *** set a breakpoint in malloc_error_break to debug
>>>
>>> So maybe svn isn't consuming memory, but is simply generating a
>>> hojillion of these error lines. I forced an abort/coredump, and found
>>> this stack:
>>>
>>> #0 0x952e329a in write$NOCANCEL$UNIX2003 ()
>>> #1 0x9538f3ce in malloc_destroy_zone ()
>>> #2 0x9538e8e3 in malloc_zone_print_ptr_info ()
>>> #3 0x9538e943 in malloc_printf ()
>>> #4 0x9538941a in scandir$INODE64 ()
>>> #5 0x952b3523 in malloc_zone_free ()
>>> #6 0x952b338d in free ()
>>> #7 0x004d230c in apr_allocator_destroy (allocator=0x502010) at
>>> memory/unix/apr_pools.c:134
>>> #8 0x000101b5 in main (argc=11, argv=0xbffff0ac) at subversion/svn/main.c:2288
>>>
>>> Any ideas?
>>>
>>> Cheers,
>>> -g
>>>
>>> On Wed, Feb 17, 2010 at 20:07, Greg Stein <gs...@gmail.com> wrote:
>>>> I'm running into a problem with merge test 4. Some kind of memory
>>>> leak, or other memory double-free or somesuch.
>>>>
>>>> During the 'svn switch', it just seems to head off into la-la land.
>>>> Consumes a TON of memory before I kill it off.
>>>>
>>>> Has anybody seen this? Ring any bells?
>>>>
>>>> Thx,
>>>> -g
>>>>
>>
>>
>> --
>> C. Michael Pilato <cm...@collab.net>
>> CollabNet <> www.collab.net <> Distributed Development On Demand
>>
>>
>
Re: memory leak? ref: merge test 4
Posted by Greg Stein <gs...@gmail.com>.
Those errors might be from the MacOS C library.
So I looked into this some more. Backdating to r886351 (when we first
bumped to format 16) would cause the problem to core dump, rather than
some weird endless hang. Bisecting the changes, I find that r906110 is
where the code switches from a core dump to a hang. It apparently
tickles wc_db in a slightly different way, and alters the resulting
symptom of some underlying double-free or somesuch.
Gotta investigate further. See if I can put in some early checks for
improper reuse or pool lifetime issues. I think the errors may be
creeping up around pool-destroy time (and trying to access the wc_db
during this time, while it is in partial-readiness).
Cheers,
-g
On Thu, Feb 18, 2010 at 11:13, C. Michael Pilato <cm...@collab.net> wrote:
> I'm not seeing this problem, but then I don't think I'm setup to generate
> stderr spam on malloc/free errors (via the likes of "MALLOC_CHECK_=1" in the
> environment or somesuch).
>
> Greg Stein wrote:
>> I think the memory usage might actually be our test harness attempting
>> to read all of the (stderr) output into memory. Thousands and
>> thousands of lines that read:
>>
>> svn(56985,0xa0634720) malloc: *** error for object 0x817a00: double free
>> *** set a breakpoint in malloc_error_break to debug
>>
>> So maybe svn isn't consuming memory, but is simply generating a
>> hojillion of these error lines. I forced an abort/coredump, and found
>> this stack:
>>
>> #0 0x952e329a in write$NOCANCEL$UNIX2003 ()
>> #1 0x9538f3ce in malloc_destroy_zone ()
>> #2 0x9538e8e3 in malloc_zone_print_ptr_info ()
>> #3 0x9538e943 in malloc_printf ()
>> #4 0x9538941a in scandir$INODE64 ()
>> #5 0x952b3523 in malloc_zone_free ()
>> #6 0x952b338d in free ()
>> #7 0x004d230c in apr_allocator_destroy (allocator=0x502010) at
>> memory/unix/apr_pools.c:134
>> #8 0x000101b5 in main (argc=11, argv=0xbffff0ac) at subversion/svn/main.c:2288
>>
>> Any ideas?
>>
>> Cheers,
>> -g
>>
>> On Wed, Feb 17, 2010 at 20:07, Greg Stein <gs...@gmail.com> wrote:
>>> I'm running into a problem with merge test 4. Some kind of memory
>>> leak, or other memory double-free or somesuch.
>>>
>>> During the 'svn switch', it just seems to head off into la-la land.
>>> Consumes a TON of memory before I kill it off.
>>>
>>> Has anybody seen this? Ring any bells?
>>>
>>> Thx,
>>> -g
>>>
>
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
Re: memory leak? ref: merge test 4
Posted by "C. Michael Pilato" <cm...@collab.net>.
I'm not seeing this problem, but then I don't think I'm setup to generate
stderr spam on malloc/free errors (via the likes of "MALLOC_CHECK_=1" in the
environment or somesuch).
Greg Stein wrote:
> I think the memory usage might actually be our test harness attempting
> to read all of the (stderr) output into memory. Thousands and
> thousands of lines that read:
>
> svn(56985,0xa0634720) malloc: *** error for object 0x817a00: double free
> *** set a breakpoint in malloc_error_break to debug
>
> So maybe svn isn't consuming memory, but is simply generating a
> hojillion of these error lines. I forced an abort/coredump, and found
> this stack:
>
> #0 0x952e329a in write$NOCANCEL$UNIX2003 ()
> #1 0x9538f3ce in malloc_destroy_zone ()
> #2 0x9538e8e3 in malloc_zone_print_ptr_info ()
> #3 0x9538e943 in malloc_printf ()
> #4 0x9538941a in scandir$INODE64 ()
> #5 0x952b3523 in malloc_zone_free ()
> #6 0x952b338d in free ()
> #7 0x004d230c in apr_allocator_destroy (allocator=0x502010) at
> memory/unix/apr_pools.c:134
> #8 0x000101b5 in main (argc=11, argv=0xbffff0ac) at subversion/svn/main.c:2288
>
> Any ideas?
>
> Cheers,
> -g
>
> On Wed, Feb 17, 2010 at 20:07, Greg Stein <gs...@gmail.com> wrote:
>> I'm running into a problem with merge test 4. Some kind of memory
>> leak, or other memory double-free or somesuch.
>>
>> During the 'svn switch', it just seems to head off into la-la land.
>> Consumes a TON of memory before I kill it off.
>>
>> Has anybody seen this? Ring any bells?
>>
>> Thx,
>> -g
>>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: memory leak? ref: merge test 4
Posted by Greg Stein <gs...@gmail.com>.
I think the memory usage might actually be our test harness attempting
to read all of the (stderr) output into memory. Thousands and
thousands of lines that read:
svn(56985,0xa0634720) malloc: *** error for object 0x817a00: double free
*** set a breakpoint in malloc_error_break to debug
So maybe svn isn't consuming memory, but is simply generating a
hojillion of these error lines. I forced an abort/coredump, and found
this stack:
#0 0x952e329a in write$NOCANCEL$UNIX2003 ()
#1 0x9538f3ce in malloc_destroy_zone ()
#2 0x9538e8e3 in malloc_zone_print_ptr_info ()
#3 0x9538e943 in malloc_printf ()
#4 0x9538941a in scandir$INODE64 ()
#5 0x952b3523 in malloc_zone_free ()
#6 0x952b338d in free ()
#7 0x004d230c in apr_allocator_destroy (allocator=0x502010) at
memory/unix/apr_pools.c:134
#8 0x000101b5 in main (argc=11, argv=0xbffff0ac) at subversion/svn/main.c:2288
Any ideas?
Cheers,
-g
On Wed, Feb 17, 2010 at 20:07, Greg Stein <gs...@gmail.com> wrote:
> I'm running into a problem with merge test 4. Some kind of memory
> leak, or other memory double-free or somesuch.
>
> During the 'svn switch', it just seems to head off into la-la land.
> Consumes a TON of memory before I kill it off.
>
> Has anybody seen this? Ring any bells?
>
> Thx,
> -g
>