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 <cmpilato_at_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 <gstein_at_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 <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
Received on 2010-02-22 03:32:40 CET