If I checkout a large working copy over https, say ^/subversion/tags, it usually
fails with:
svn: E235000: In file '../src/subversion/libsvn_wc/wc_db.c' line 1707: assertion
failed (SVN_IS_VALID_REVNUM(changed_rev))
The stacktrace shows svn_wc__db_base_add_file called from the update editor's
close_file callback. All of changed_rev/date/author are unset. It looks like the
properties have not been received.
If I patch the client:
Index: ../src/subversion/libsvn_wc/update_editor.c
===================================================================
--- ../src/subversion/libsvn_wc/update_editor.c (revision 1350025)
+++ ../src/subversion/libsvn_wc/update_editor.c (working copy)
@@ -4480,6 +4480,14 @@
if (new_checksum == NULL)
new_checksum = fb->original_checksum;
+#if 1
+ if (!SVN_IS_VALID_REVNUM(fb->changed_rev))
+ {
+ fb->changed_rev = 1;
+ printf("!!!!!!!FIX: %s changed_rev\n", fb->local_abspath);
+ }
+#endif
+
SVN_ERR(svn_wc__db_base_add_file(eb->db, fb->local_abspath,
eb->wcroot_abspath,
fb->new_relpath,
that fixes the assert but the client crashes soon afterwards. A typical crash is:
!!!!!!!FIX:
/home/pm/sw/subversion/obj/wc/0.22.0/subversion/tests/clients/cmdline/getopt_tests_data/svn_help_stdout
changed_rev
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6d3aeef in ?? () from /usr/lib/libapr-1.so.0
(gdb) up
#1 0x00007ffff6d3b23e in apr_hash_get () from /usr/lib/libapr-1.so.0
(gdb)
#2 0x00007ffff5ee58cd in svn_ra_serf__set_ver_prop (props=0x7fffec30c0c8,
path=0x7fffec30c268
"/repos/asf/!svn/rvr/849186/subversion/tags/0.22.0/subversion/tests/clients/cmdline/getopt_tests_data/svn_help_stdout",
rev=1350028,
ns=0x7fffec30c128 "DAV:", name=0x7fffec30c130 "href", val=0x7fffec30c0a0,
pool=0x7fffec30c028) at ../src/subversion/libsvn_ra_serf/property.c:187
187 ver_props = apr_hash_get(props, &rev, sizeof(rev));
(gdb)
#3 0x00007ffff5ee5fbd in end_propfind (parser=0x7fffec123f38, name=...,
scratch_pool=0x7fffea402028)
at ../src/subversion/libsvn_ra_serf/property.c:375
375 svn_ra_serf__set_ver_prop(ctx->ret_props,
(gdb)
#4 0x00007ffff5ef5c94 in end_xml (userData=0x7fffec123f38,
raw_name=0xa8f8d0 "D:href") at ../src/subversion/libsvn_ra_serf/util.c:1243
1243 err = parser->end(parser, name, scratch_pool);
(gdb)
#5 0x00007ffff5a986f4 in ?? () from /lib/x86_64-linux-gnu/libexpat.so.1
(gdb)
#6 0x00007ffff5a99951 in ?? () from /lib/x86_64-linux-gnu/libexpat.so.1
(gdb)
#7 0x00007ffff5a967c7 in ?? () from /lib/x86_64-linux-gnu/libexpat.so.1
(gdb)
#8 0x00007ffff5a9817b in ?? () from /lib/x86_64-linux-gnu/libexpat.so.1
(gdb)
#9 0x00007ffff5a9b75d in XML_ParseBuffer ()
from /lib/x86_64-linux-gnu/libexpat.so.1
(gdb)
#10 0x00007ffff5ef5f20 in inject_to_parser (ctx=0x7fffec123f38,
data=0x7ffff2abd01c "<?xml version=\"1.0\"
encoding=\"utf-8\"?>\n<D:multistatus xmlns:D=\"DAV:\"
xmlns:ns0=\"DAV:\">\n<D:response
xmlns:S=\"http://subversion.tigris.org/xmlns/svn/\"
xmlns:C=\"http://subversion.tigris.org/xmlns/custom/"..., len=1855,
sl=0x7fffffffda90)
at ../src/subversion/libsvn_ra_serf/util.c:1324
1324 xml_status = XML_Parse(ctx->xmlp, data, (int) len, 0);
(gdb)
#11 0x00007ffff5ef673a in svn_ra_serf__handle_xml_parser (
request=0x7fffeffac638, response=0x7fffebaec238, baton=0x7fffec123f38,
pool=0x7fffea410028) at ../src/subversion/libsvn_ra_serf/util.c:1587
1587 err = inject_to_parser(ctx, data, len, &sl);
(gdb)
#12 0x00007ffff5ef728c in handle_response (request=0x7fffeffac638,
response=0x7fffebaec238, handler=0x7fffec123e98,
serf_status=0x7fffffffdc18, scratch_pool=0x7fffea410028)
at ../src/subversion/libsvn_ra_serf/util.c:1948
1948 err = handler->response_handler(request, response,
Note that the crash happens as serf is processing properties for
0.22.0/subversion/tests/clients/cmdline/getopt_tests_data/svn_help_stdout
that's the file that would have caused the assert if not fixed by the patch.
So it appears that serf is processing the properties for an added file after the
close_file callback is invoked.