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):
#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.
Thanks,
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 13 17:18:26 2005