You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Anatoly Orlov <an...@yandex.ru> on 2014/02/19 19:03:47 UTC
issue validation: bug, Memcached+FullText cache is totally broken in svnserve 1.8.5
Hi.
Preface:
We are trying to migrate to svn 1.8.5, with very large repository(~700G), with heavy load(1000+ developers, 200+ test servers) since we use svn+ssh memcached is reasonable cache system for us.
Problem:
Enabling memcached with full text caches in version 1.8.5. causes svnserve -t segfault just after first cache hit to memcached.
Reason:
memcache_get lack deserialiser for memcached full texts, and uses default one, which returns svn_string_t* in first parameter (thru void**) at cache-memcache.c:206.
This value is returned as void** thru svn_cache__get at cache.c:67 to read_representation at temp_serializer.c:5298
read_representation interpret this void** as svn_stringbuf_t* and puts this value into stream baton.
baton is used in read_handler_stringbuf at in stream.c:1397 and cause crash (because len and data in svn_string_t and svn_stringbuf_t are effectively changed places)
Traceback:
#0 0x00007ffff58ea932 in memcpy () from /lib64/libc.so.6
#1 0x00007ffff73427cc in read_handler_stringbuf (baton=0x81ed98, buffer=<value optimized out>, len=0x81eb38)
at /usr/include/bits/string3.h:52
#2 0x00007fffed579f6d in get_dir_contents (entries_p=0x7fffffffdc60, fs=0x6451a8, noderev=0x6877a8, pool=0x81ca98)
at subversion/libsvn_fs_fs/fs_fs.c:5524
#3 svn_fs_fs__rep_contents_dir (entries_p=0x7fffffffdc60, fs=0x6451a8, noderev=0x6877a8, pool=0x81ca98)
at subversion/libsvn_fs_fs/fs_fs.c:5679
#4 0x00007fffed57a47d in svn_fs_fs__rep_contents_dir_entry (dirent=0x7fffffffdcf8, fs=0x6451a8, noderev=0x6877a8,
name=0x687940 "trunk", result_pool=0x81ca98, scratch_pool=0x81ca98) at subversion/libsvn_fs_fs/fs_fs.c:5727
#5 0x00007fffed5686ac in svn_fs_fs__dag_dir_entry (dirent=0x7fffffffdcf8, node=0x687720, name=0x687940 "trunk", pool=0x81ca98)
at subversion/libsvn_fs_fs/dag.c:445
#6 0x00007fffed5686e9 in dir_entry_id_from_node (child_p=0x7fffffffddd8, parent=0x687720, name=<value optimized out>,
result_pool=0x6872b8, scratch_pool=<value optimized out>) at subversion/libsvn_fs_fs/dag.c:315
#7 svn_fs_fs__dag_open (child_p=0x7fffffffddd8, parent=0x687720, name=<value optimized out>, result_pool=0x6872b8,
scratch_pool=<value optimized out>) at subversion/libsvn_fs_fs/dag.c:1164
#8 0x00007fffed583a77 in open_path (parent_path_p=0x7fffffffde38, root=0x81c0b0, path=0x6874c8 "/trunk/arcadia", flags=6,
txn_id=0x0, pool=0x6872b8) at subversion/libsvn_fs_fs/tree.c:1006
#9 0x00007fffed583ecb in get_dag (dag_node_p=0x7fffffffde78, root=0x81c0b0, path=0x6874c8 "/trunk/arcadia", needs_lock_cache=0,
pool=0x6872b8) at subversion/libsvn_fs_fs/tree.c:1213
#10 0x00007fffed583fda in svn_fs_fs__node_id (id_p=0x7fffffffdea8, root=<value optimized out>, path=<value optimized out>,
pool=0x6872b8) at subversion/libsvn_fs_fs/tree.c:1284
#11 0x00007fffed58407b in node_kind (kind_p=0x7fffffffdefc, root=0x81c0b0, path=<value optimized out>, pool=0x6872b8)
at subversion/libsvn_fs_fs/tree.c:1333
#12 svn_fs_fs__check_path (kind_p=0x7fffffffdefc, root=0x81c0b0, path=<value optimized out>, pool=0x6872b8)
at subversion/libsvn_fs_fs/tree.c:1352
#13 0x000000000040c933 in check_path (conn=0x633000, pool=0x6872b8, params=<value optimized out>, baton=0x7fffffffe040)
at subversion/svnserve/serve.c:2280
#14 0x00007ffff707f063 in svn_ra_svn__handle_commands2 (conn=0x633000, pool=<value optimized out>, commands=<value optimized out>,
baton=0x7fffffffe040, error_on_disconnect=0) at subversion/libsvn_ra_svn/marshal.c:1494
#15 0x000000000040bc2d in serve (conn=0x633000, params=<value optimized out>, pool=0x627508) at subversion/svnserve/serve.c:3678
#16 0x000000000040fa5f in main (argc=<value optimized out>, argv=<value optimized out>) at subversion/svnserve/svnserve.c:844
Could somebody confirm the issue and/or recommend workaround?
Re: issue validation: bug, Memcached+FullText cache is totally
broken in svnserve 1.8.5
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Feb 19, 2014 at 10:03:47PM +0400, Anatoly Orlov wrote:
> Hi.
>
> Preface:
> We are trying to migrate to svn 1.8.5, with very large repository(~700G), with heavy load(1000+ developers, 200+ test servers) since we use svn+ssh memcached is reasonable cache system for us.
>
> Problem:
> Enabling memcached with full text caches in version 1.8.5. causes svnserve -t segfault just after first cache hit to memcached.
>
> Reason:
> memcache_get lack deserialiser for memcached full texts, and uses default one, which returns svn_string_t* in first parameter (thru void**) at cache-memcache.c:206.
> This value is returned as void** thru svn_cache__get at cache.c:67 to read_representation at temp_serializer.c:5298
> read_representation interpret this void** as svn_stringbuf_t* and puts this value into stream baton.
> baton is used in read_handler_stringbuf at in stream.c:1397 and cause crash (because len and data in svn_string_t and svn_stringbuf_t are effectively changed places)
>
> Traceback:
> #0 0x00007ffff58ea932 in memcpy () from /lib64/libc.so.6
> #1 0x00007ffff73427cc in read_handler_stringbuf (baton=0x81ed98, buffer=<value optimized out>, len=0x81eb38)
> at /usr/include/bits/string3.h:52
> #2 0x00007fffed579f6d in get_dir_contents (entries_p=0x7fffffffdc60, fs=0x6451a8, noderev=0x6877a8, pool=0x81ca98)
> at subversion/libsvn_fs_fs/fs_fs.c:5524
> #3 svn_fs_fs__rep_contents_dir (entries_p=0x7fffffffdc60, fs=0x6451a8, noderev=0x6877a8, pool=0x81ca98)
> at subversion/libsvn_fs_fs/fs_fs.c:5679
> #4 0x00007fffed57a47d in svn_fs_fs__rep_contents_dir_entry (dirent=0x7fffffffdcf8, fs=0x6451a8, noderev=0x6877a8,
> name=0x687940 "trunk", result_pool=0x81ca98, scratch_pool=0x81ca98) at subversion/libsvn_fs_fs/fs_fs.c:5727
> #5 0x00007fffed5686ac in svn_fs_fs__dag_dir_entry (dirent=0x7fffffffdcf8, node=0x687720, name=0x687940 "trunk", pool=0x81ca98)
> at subversion/libsvn_fs_fs/dag.c:445
> #6 0x00007fffed5686e9 in dir_entry_id_from_node (child_p=0x7fffffffddd8, parent=0x687720, name=<value optimized out>,
> result_pool=0x6872b8, scratch_pool=<value optimized out>) at subversion/libsvn_fs_fs/dag.c:315
> #7 svn_fs_fs__dag_open (child_p=0x7fffffffddd8, parent=0x687720, name=<value optimized out>, result_pool=0x6872b8,
> scratch_pool=<value optimized out>) at subversion/libsvn_fs_fs/dag.c:1164
> #8 0x00007fffed583a77 in open_path (parent_path_p=0x7fffffffde38, root=0x81c0b0, path=0x6874c8 "/trunk/arcadia", flags=6,
> txn_id=0x0, pool=0x6872b8) at subversion/libsvn_fs_fs/tree.c:1006
> #9 0x00007fffed583ecb in get_dag (dag_node_p=0x7fffffffde78, root=0x81c0b0, path=0x6874c8 "/trunk/arcadia", needs_lock_cache=0,
> pool=0x6872b8) at subversion/libsvn_fs_fs/tree.c:1213
> #10 0x00007fffed583fda in svn_fs_fs__node_id (id_p=0x7fffffffdea8, root=<value optimized out>, path=<value optimized out>,
> pool=0x6872b8) at subversion/libsvn_fs_fs/tree.c:1284
> #11 0x00007fffed58407b in node_kind (kind_p=0x7fffffffdefc, root=0x81c0b0, path=<value optimized out>, pool=0x6872b8)
> at subversion/libsvn_fs_fs/tree.c:1333
> #12 svn_fs_fs__check_path (kind_p=0x7fffffffdefc, root=0x81c0b0, path=<value optimized out>, pool=0x6872b8)
> at subversion/libsvn_fs_fs/tree.c:1352
> #13 0x000000000040c933 in check_path (conn=0x633000, pool=0x6872b8, params=<value optimized out>, baton=0x7fffffffe040)
> at subversion/svnserve/serve.c:2280
> #14 0x00007ffff707f063 in svn_ra_svn__handle_commands2 (conn=0x633000, pool=<value optimized out>, commands=<value optimized out>,
> baton=0x7fffffffe040, error_on_disconnect=0) at subversion/libsvn_ra_svn/marshal.c:1494
> #15 0x000000000040bc2d in serve (conn=0x633000, params=<value optimized out>, pool=0x627508) at subversion/svnserve/serve.c:3678
> #16 0x000000000040fa5f in main (argc=<value optimized out>, argv=<value optimized out>) at subversion/svnserve/svnserve.c:844
>
> Could somebody confirm the issue and/or recommend workaround?
Yes, please file an issue. This has clearly not been tested before release :(
As a workaround you will need to disable caching, as the in-process cache of
svnserve won't really help you with svn+ssh unfortunately.
This shouldn't be very hard to fix. But the next 1.8 release has just
been prepared so you probably won't see a patched release for a few weeks.