You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by we...@tigris.org on 2009/03/11 20:55:23 UTC
Subversion abort doing --reintegrate with large number of files
with serf
As the subject line says.
Stack backtrace from gdb (with filenames removed)...
#0 0xb7fa2410 in __kernel_vsyscall ()
#1 0xb793c085 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb793da01 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7e55064 in serf_bucket_mem_free (allocator=0x96d5160, block=0xa00) at buckets/allocator.c:228
#4 0xb7e53a3c in serf_default_destroy_and_data (bucket=0xb6d7278) at buckets/buckets.c:117
#5 0xb7e51b4f in serf_aggregate_destroy_and_data (bucket=0xb6d7278) at buckets/aggregate_buckets.c:75
#6 0xb7e5730b in serf_chunk_destroy (bucket=0xbb606a8) at buckets/chunk_buckets.c:220
#7 0xb7e51a01 in cleanup_aggregate (ctx=0xbb602a8, allocator=0xbb45a70) at buckets/aggregate_buckets.c:43
#8 0xb7e51b44 in serf_aggregate_destroy_and_data (bucket=0xbb5fc28) at buckets/aggregate_buckets.c:73
#9 0xb7e530a8 in serf_context_run (ctx=0x96d51f8, duration=2000000000, pool=0xba38f00) at context.c:652
#10 0xb7e74498 in svn_ra_serf__context_run_wait (done=0xba38fb8, sess=0x80a2be8, pool=0xba38f00) at subversion/libsvn_ra_serf/util.c:547
#11 0xb7e64b17 in svn_ra_serf__get_location_segments (ra_session=0x80a2bd8, path=0xba38f38 "xxxx/xxxx",
peg_revision=14079, start_rev=14079, end_rev=-1, receiver=0xb7f95d30 <gls_receiver>, receiver_baton=0xbfa44e80, pool=0xba38f00)
at subversion/libsvn_ra_serf/getlocationsegments.c:217
#12 0xb7f25dcf in svn_ra_get_location_segments (session=0x80a2bd8, path=0xba38f38 "xxxx/xxxx", peg_revision=14079,
start_rev=14079, end_rev=-1, receiver=0xb7f95d30 <gls_receiver>, receiver_baton=0xbfa44e80, pool=0xba38f00) at subversion/libsvn_ra/ra_loader.c:1080
#13 0xb7f95cf2 in svn_client__repos_location_segments (segments=0xbfa45028, ra_session=0x80a2bd8,
path=0xba38f38 "xxxx/xxxx", peg_revision=14079, start_revision=14079, end_revision=-1, ctx=0x807eab8,
pool=0xba38f00) at subversion/libsvn_client/ra.c:594
#14 0xb7f8fab0 in svn_client_merge_reintegrate (source=0x809ba48 "xxxx/xxxx",
peg_revision=0xbfa45108, target_wcpath=0x805db4f "", dry_run=0, merge_options=0x0, ctx=0x807eab8, pool=0x807e1e0)
at subversion/libsvn_client/merge.c:6847
#15 0x0805540b in svn_cl__merge (os=0x807e380, baton=0xbfa452f8, pool=0x807e1e0) at subversion/svn/merge-cmd.c:300
#16 0x0805464d in main (argc=Cannot access memory at address 0xa00
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1309410
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion abort doing --reintegrate with large number of files
with serf
Posted by Lieven Govaerts <sv...@mobsol.be>.
webpost@tigris.org wrote:
>> What version of svn are you using? And serf?
>>
>> There are some fixes related to this issue in the 1.6rc code, just
>> wondering if you're using them.
>
> Sorry, meant to include that in the original post, but I hit send before I put them in. It's the subversion 1.5.6 release, using serf from the 1.5.6 subversion-deps
>
> $ svn --version
> svn, version 1.5.6 (r36142)
> compiled Mar 11 2009, 11:13:46
>
> $ ldd /opt/subversion-1.5/bin/svn
> ...stuff removed...
> libsvn_ra_serf-1.so.0 => /opt/subversion-1.5/lib/libsvn_ra_serf-1.so.0
>
Subversion 1.5 over serf has a known issue that shows up often with
merge or merge-related actions. The issue results in an abort in the
serf bucket allocator (double freeing of memory).
As fixing the issue required a new feature in serf (released in version
0.3), the fix could only be included in subversion 1.6.
See issue 3212 for more info:
http://subversion.tigris.org/issues/show_bug.cgi?id=3212
Lieven
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1326953
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Re: Subversion abort doing --reintegrate with large number of
files with serf
Posted by we...@tigris.org.
> What version of svn are you using? And serf?
>
> There are some fixes related to this issue in the 1.6rc code, just
> wondering if you're using them.
Sorry, meant to include that in the original post, but I hit send before I put them in. It's the subversion 1.5.6 release, using serf from the 1.5.6 subversion-deps
$ svn --version
svn, version 1.5.6 (r36142)
compiled Mar 11 2009, 11:13:46
$ ldd /opt/subversion-1.5/bin/svn
...stuff removed...
libsvn_ra_serf-1.so.0 => /opt/subversion-1.5/lib/libsvn_ra_serf-1.so.0
>
> Lieven
>
> webpost@tigris.org wrote:
> > As the subject line says.
> >
> > Stack backtrace from gdb (with filenames removed)...
> >
> > #0 0xb7fa2410 in __kernel_vsyscall ()
> > #1 0xb793c085 in raise () from /lib/tls/i686/cmov/libc.so.6
> > #2 0xb793da01 in abort () from /lib/tls/i686/cmov/libc.so.6
> > #3 0xb7e55064 in serf_bucket_mem_free (allocator=0x96d5160, block=0xa00) at buckets/allocator.c:228
> > #4 0xb7e53a3c in serf_default_destroy_and_data (bucket=0xb6d7278) at buckets/buckets.c:117
> > #5 0xb7e51b4f in serf_aggregate_destroy_and_data (bucket=0xb6d7278) at buckets/aggregate_buckets.c:75
> > #6 0xb7e5730b in serf_chunk_destroy (bucket=0xbb606a8) at buckets/chunk_buckets.c:220
> > #7 0xb7e51a01 in cleanup_aggregate (ctx=0xbb602a8, allocator=0xbb45a70) at buckets/aggregate_buckets.c:43
> > #8 0xb7e51b44 in serf_aggregate_destroy_and_data (bucket=0xbb5fc28) at buckets/aggregate_buckets.c:73
> > #9 0xb7e530a8 in serf_context_run (ctx=0x96d51f8, duration=2000000000, pool=0xba38f00) at context.c:652
> > #10 0xb7e74498 in svn_ra_serf__context_run_wait (done=0xba38fb8, sess=0x80a2be8, pool=0xba38f00) at subversion/libsvn_ra_serf/util.c:547
> > #11 0xb7e64b17 in svn_ra_serf__get_location_segments (ra_session=0x80a2bd8, path=0xba38f38 "xxxx/xxxx",
> > peg_revision=14079, start_rev=14079, end_rev=-1, receiver=0xb7f95d30 <gls_receiver>, receiver_baton=0xbfa44e80, pool=0xba38f00)
> > at subversion/libsvn_ra_serf/getlocationsegments.c:217
> > #12 0xb7f25dcf in svn_ra_get_location_segments (session=0x80a2bd8, path=0xba38f38 "xxxx/xxxx", peg_revision=14079,
> > start_rev=14079, end_rev=-1, receiver=0xb7f95d30 <gls_receiver>, receiver_baton=0xbfa44e80, pool=0xba38f00) at subversion/libsvn_ra/ra_loader.c:1080
> > #13 0xb7f95cf2 in svn_client__repos_location_segments (segments=0xbfa45028, ra_session=0x80a2bd8,
> > path=0xba38f38 "xxxx/xxxx", peg_revision=14079, start_revision=14079, end_revision=-1, ctx=0x807eab8,
> > pool=0xba38f00) at subversion/libsvn_client/ra.c:594
> > #14 0xb7f8fab0 in svn_client_merge_reintegrate (source=0x809ba48 "xxxx/xxxx",
> > peg_revision=0xbfa45108, target_wcpath=0x805db4f "", dry_run=0, merge_options=0x0, ctx=0x807eab8, pool=0x807e1e0)
> > at subversion/libsvn_client/merge.c:6847
> > #15 0x0805540b in svn_cl__merge (os=0x807e380, baton=0xbfa452f8, pool=0x807e1e0) at subversion/svn/merge-cmd.c:300
> > #16 0x0805464d in main (argc=Cannot access memory at address 0xa00
> >
> > ------------------------------------------------------
> > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1309410
> >
> > To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
> >
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1314595
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion abort doing --reintegrate with large number of files
with serf
Posted by Lieven Govaerts <sv...@mobsol.be>.
What version of svn are you using? And serf?
There are some fixes related to this issue in the 1.6rc code, just
wondering if you're using them.
Lieven
webpost@tigris.org wrote:
> As the subject line says.
>
> Stack backtrace from gdb (with filenames removed)...
>
> #0 0xb7fa2410 in __kernel_vsyscall ()
> #1 0xb793c085 in raise () from /lib/tls/i686/cmov/libc.so.6
> #2 0xb793da01 in abort () from /lib/tls/i686/cmov/libc.so.6
> #3 0xb7e55064 in serf_bucket_mem_free (allocator=0x96d5160, block=0xa00) at buckets/allocator.c:228
> #4 0xb7e53a3c in serf_default_destroy_and_data (bucket=0xb6d7278) at buckets/buckets.c:117
> #5 0xb7e51b4f in serf_aggregate_destroy_and_data (bucket=0xb6d7278) at buckets/aggregate_buckets.c:75
> #6 0xb7e5730b in serf_chunk_destroy (bucket=0xbb606a8) at buckets/chunk_buckets.c:220
> #7 0xb7e51a01 in cleanup_aggregate (ctx=0xbb602a8, allocator=0xbb45a70) at buckets/aggregate_buckets.c:43
> #8 0xb7e51b44 in serf_aggregate_destroy_and_data (bucket=0xbb5fc28) at buckets/aggregate_buckets.c:73
> #9 0xb7e530a8 in serf_context_run (ctx=0x96d51f8, duration=2000000000, pool=0xba38f00) at context.c:652
> #10 0xb7e74498 in svn_ra_serf__context_run_wait (done=0xba38fb8, sess=0x80a2be8, pool=0xba38f00) at subversion/libsvn_ra_serf/util.c:547
> #11 0xb7e64b17 in svn_ra_serf__get_location_segments (ra_session=0x80a2bd8, path=0xba38f38 "xxxx/xxxx",
> peg_revision=14079, start_rev=14079, end_rev=-1, receiver=0xb7f95d30 <gls_receiver>, receiver_baton=0xbfa44e80, pool=0xba38f00)
> at subversion/libsvn_ra_serf/getlocationsegments.c:217
> #12 0xb7f25dcf in svn_ra_get_location_segments (session=0x80a2bd8, path=0xba38f38 "xxxx/xxxx", peg_revision=14079,
> start_rev=14079, end_rev=-1, receiver=0xb7f95d30 <gls_receiver>, receiver_baton=0xbfa44e80, pool=0xba38f00) at subversion/libsvn_ra/ra_loader.c:1080
> #13 0xb7f95cf2 in svn_client__repos_location_segments (segments=0xbfa45028, ra_session=0x80a2bd8,
> path=0xba38f38 "xxxx/xxxx", peg_revision=14079, start_revision=14079, end_revision=-1, ctx=0x807eab8,
> pool=0xba38f00) at subversion/libsvn_client/ra.c:594
> #14 0xb7f8fab0 in svn_client_merge_reintegrate (source=0x809ba48 "xxxx/xxxx",
> peg_revision=0xbfa45108, target_wcpath=0x805db4f "", dry_run=0, merge_options=0x0, ctx=0x807eab8, pool=0x807e1e0)
> at subversion/libsvn_client/merge.c:6847
> #15 0x0805540b in svn_cl__merge (os=0x807e380, baton=0xbfa452f8, pool=0x807e1e0) at subversion/svn/merge-cmd.c:300
> #16 0x0805464d in main (argc=Cannot access memory at address 0xa00
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1309410
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1313878
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].