[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

issue validation: bug, Memcached+FullText cache is totally broken in svnserve 1.8.5

From: Anatoly Orlov <anatolix_at_yandex.ru>
Date: Wed, 19 Feb 2014 22:03:47 +0400

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?
Received on 2014-02-19 19:15:19 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.