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.
