On Wednesday 13 July 2005 11:16, Brian Buesker wrote:
> John Szakmeister wrote:
> >On Wednesday 13 July 2005 01:30, Brian Buesker wrote:
> >>Sorry, I forgot to attach the log. Here it is.
> >
> >I have proposed a change for the 1.2 branch that clears up quite a bit
> > of the memory usage in merge operations (r15233). Would you care to
> > try the current Subversion trunk/?
>
> Ok, I tried the trunk version at r15233. I couldn't go with a later rev
> of /trunk as that broke the building of the svn perl bindings (possibly
> due to changes made to support SWIG 1.3.25). However, r15233 didn't
> seem to fix the problem, as I still saw the memory usage growing. And
> in fact, after 4 merges, I got a segfault. Here is the stack trace from
> that (I replaced the path in frames #3 and #4 with just "..." as I
> didn't want to include the path in the mail. The path is indeed a valid
> path to a directory in both cases though):
Can you try using the 1.2.1 release and just merging in r15233? I think
the segfault is an unrelated issue relating the the new property merging
algorithm.
> #0 0x00efae82 in find_entry (ht=0x0, key=0xdc1a2f0, klen=8, val=0x0)
> at apr_hash.c:235
> #1 0x00efb08d in apr_hash_get (ht=0x0, key=0xdd2ef10a,
> klen=-1579507087) at apr_hash.c:297
> #2 0x0024887e in svn_wc__merge_props (state=0xbff60748,
> adm_access=0xdb436f8, name=0x0, server_baseprops=0x0,
> propchanges=0xdc17108, base_merge=0, dry_run=0, pool=0xdc170d0,
> entry_accum=0xbff606ac)
> at subversion/libsvn_wc/props.c:424
> #3 0x002484e7 in svn_wc_merge_props (state=0xbff60748,
> path=0xdc15200 "...", adm_access=0xdb436f8, baseprops=0x0,
> propchanges=0xdc17108, base_merge=0, dry_run=0, pool=0xdc170d0)
> at subversion/libsvn_wc/props.c:315
> #4 0x00acad8c in merge_props_changed (adm_access=0xdb436f8,
> state=0xbff60748, path=0xdc15200 "...", propchanges=0xdc15258,
> original_props=0x0, baton=0xbff60bc0) at
> subversion/libsvn_client/diff.c:731
> #5 0x00ad9acc in close_directory (dir_baton=0xdc151a8, pool=0xdc150c8)
> at subversion/libsvn_client/repos_diff.c:879
> #6 0x00992df6 in close_directory (dir_baton=0xdc151a0, pool=0xdc150c8)
> at subversion/libsvn_delta/cancel.c:266
> #7 0x00d21a1f in end_element (userdata=0xcde8408, state=222,
> nspace=0xdc04f28 "svn:", elt_name=0xdc33de0 "add-directory")
> at subversion/libsvn_ra_dav/fetch.c:2510
> #8 0x001de6fd in end_element () from
> /opt/or-buildtools/lib/libneon.so.24 #9 0x00f4415d in xmlParseTextDecl
> () from /usr/lib/libxml2.so.2 #10 0x00fcf617 in xmlParseChunk () from
> /usr/lib/libxml2.so.2
> #11 0x00000000 in ?? ()
>
> Please let me know if you want any more information.
>
> BTW - I have seen merges for large working copies consuming a lot of
> memory, so if r15233 is meant to fix just this case, that would still
> be nice. I don't know if the segfault is coming due to that fix or
> something else.
r15233 reduced one person's memory usage from over 2GB to 60MB, but you're
situation may be different. If you can apply that diff to a 1.2.1
release, and give it a whirl, you might have better luck. I'm hoping the
patch makes it into the next bugfix release.
As for the segfault, I think that's a result of a new property merging
algorithm. And actually, if you can provide information about the couple
of revs that produced that (what changes were involved, and how yoou
executed the command), it could be helpful in tracking down that bug.
Thanks!
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 13 20:43:20 2005