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 <gst...@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 <cmpil...@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 <gst...@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 <cmpil...@collab.net> >> CollabNet <> www.collab.net <> Distributed Development On Demand >> >> >
