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

Re: Random serf checkout failures

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: Fri, 2 Nov 2012 21:28:09 +0100


On Thu, Nov 1, 2012 at 1:29 PM, Philip Martin <philip_at_codematters.co.uk> wrote:
> I've been experimenting checking out subversion/tags from my local
> mirror of the Subversion repository using a client and mod_dav_svn from
> trunk. I'm getting several different errors seemingly at random, I
> suspect they may be related to some common underlying problem.
> Sometimes I see a checksum error such as this:
> ../src/subversion/svn/checkout-cmd.c:168: (apr_err=200014)
> ../src/subversion/libsvn_client/checkout.c:179: (apr_err=200014)
> ../src/subversion/libsvn_client/update.c:579: (apr_err=200014)
> ../src/subversion/libsvn_client/update.c:440: (apr_err=200014)
> ../src/subversion/libsvn_wc/adm_crawler.c:858: (apr_err=200014)
> ../src/subversion/libsvn_ra_serf/update.c:2515: (apr_err=200014)
> ../src/subversion/libsvn_ra_serf/util.c:2023: (apr_err=200014)
> ../src/subversion/libsvn_ra_serf/util.c:2004: (apr_err=200014)
> ../src/subversion/libsvn_ra_serf/update.c:1065: (apr_err=200014)
> ../src/subversion/libsvn_ra_serf/update.c:895: (apr_err=200014)
> ../src/subversion/libsvn_wc/update_editor.c:3919: (apr_err=200014)
> ../src/subversion/libsvn_subr/checksum.c:469: (apr_err=200014)
> svn: E200014: Checksum mismatch for '/home/pm/sw/subversion/obj/wc/0.25.0/subversion/libsvn_fs/tree.c':
> expected: c38c3e8df15f36a45b8a626e4d82a25d
> actual: 2532722e781ef9afe673c89fd467d5f0
> The expected checksum is the checksum in the repository. It's a
> different file each time this error occurs.
> Another error is an assert:
> Program received signal SIGABRT, Aborted.
> 0x00007ffff6530425 in __GI_raise (sig=<optimised out>)
> at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0 0x00007ffff6530425 in __GI_raise (sig=<optimised out>)
> at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x00007ffff6533b8b in __GI_abort () at abort.c:91
> #2 0x00007ffff6d41b78 in svn_error_abort_on_malfunction (can_return=1,
> file=0x7ffff5a97058 "../src/subversion/libsvn_ra_serf/update.c", line=673,
> expr=0x7ffff5a970fe "! dir->ref_count")
> at ../src/subversion/libsvn_subr/error.c:678
> #3 0x00007ffff6d41bcc in svn_error__malfunction (can_return=1,
> file=0x7ffff5a97058 "../src/subversion/libsvn_ra_serf/update.c", line=673,
> expr=0x7ffff5a970fe "! dir->ref_count")
> at ../src/subversion/libsvn_subr/error.c:703
> #4 0x00007ffff5a85d50 in close_all_dirs (dir=0x7fffe885f0c8)
> at ../src/subversion/libsvn_ra_serf/update.c:673
> #5 0x00007ffff5a85cda in close_all_dirs (dir=0x7fffe88d00c8)
> at ../src/subversion/libsvn_ra_serf/update.c:669
> #6 0x00007ffff5a85cda in close_all_dirs (dir=0x7fffe89860c8)
> at ../src/subversion/libsvn_ra_serf/update.c:669
> #7 0x00007ffff5a85cda in close_all_dirs (dir=0x7ffff7f2a0c8)
> at ../src/subversion/libsvn_ra_serf/update.c:669
> #8 0x00007ffff5a8b01b in finish_report (report_baton=0x7ffff7fb8060,
> pool=0x7ffff7fb5028) at ../src/subversion/libsvn_ra_serf/update.c:2665
> #9 0x00007ffff76945cc in svn_wc_crawl_revisions5 (wc_ctx=0x7ffff7f670e0,
> local_abspath=0x7ffff7fb5168 "/home/pm/sw/subversion/obj/wc",
> reporter=0x7ffff5ca07c0, report_baton=0x7ffff7fb8060, restore_files=1,
> depth=svn_depth_unknown, honor_depth_exclude=1,
> depth_compatibility_trick=0, use_commit_times=0,
> cancel_func=0x416b1b <svn_cl__check_cancel>, cancel_baton=0x0,
> notify_func=0x41c703 <notify>, notify_baton=0x7ffff7f673d0,
> scratch_pool=0x7ffff7fb5028)
> at ../src/subversion/libsvn_wc/adm_crawler.c:858
> This appears to be in the end of the checkout code but the working copy
> is far from complete.
> I have also seen this error:
> ../src/subversion/svn/checkout-cmd.c:168: (apr_err=175009)
> ../src/subversion/libsvn_client/checkout.c:179: (apr_err=175009)
> ../src/subversion/libsvn_client/update.c:579: (apr_err=175009)
> ../src/subversion/libsvn_client/update.c:440: (apr_err=175009)
> ../src/subversion/libsvn_wc/adm_crawler.c:858: (apr_err=175009)
> ../src/subversion/libsvn_ra_serf/update.c:2515: (apr_err=175009)
> ../src/subversion/libsvn_ra_serf/util.c:2028: (apr_err=175009)
> ../src/subversion/libsvn_ra_serf/util.c:1850: (apr_err=175009)
> svn: E175009: Premature EOF seen from server (http status=200)
> ../src/subversion/libsvn_ra_serf/util.c:1850: (apr_err=70014)
> svn: E070014: End of file found
> All of these look like some problem with the data transfer, serf losing
> data or mod_dav_svn not sending it, but I suppose they could also be
> caused by memory corruption. These errors generally occur when there
> are thousands of files in the pristine store and tens of thousands of
> files in the working copy.
> I've seen these error while checking out across my LAN and on localhost
> so I don't think it can be network problem. I'm using serf 1.1.x_at_1674
> and subversion/mod_dav_svn from trunk (currently r1404529 but I was
> seeing these errors a couple of weeks ago as well). I'm seeing these
> errors on Debian/stable and Ubuntu/12.04.

Are you using https or http?

I've done similar tests with success recently, but that was on
Windows. This was to the European mirror of the apache repository
though, I don't have a local mirror available.

Are you willing to use serf trunk instead of 1.1.x? I've added logging
to serf trunk, which has helped me a lot in analyzing serf behavior.
The relevant flags are in serf_private.h. I'd set SOCK_VERBOSE,
SOCK_MSG_VERBOSE. All output is written to stderr so easy to redirect
to file.

> --
> Philip

Received on 2012-11-02 21:35:42 CET

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