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 <gstein_at_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 <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-03-02 02:35:19 CET