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

RE: Endless loop in handle_fetch routine of trunk/subversion/libsvn_ra_serv/update.c

From: Marc Haesen <marc.haesen_at_oneaccess-net.com>
Date: Thu, 11 Jun 2009 09:28:28 +0200

Hi Neels,

I am not able to reproduce this particular problem. However I have a
similar problem in the case the server containing the repository is
down.

I am using trunk revision 37981 on windows. I did a clean build.
When doing the 'svn up' command on a working copy when the server
(apache with mod_dav_svn) is down, I get an endless loop in
svn_ra_serf__context_run_wait (subversion/libsvn_ra_serf/util.c)
The command does not produce any output.
I would have expected the svn up command return an error after a
time-out.

When I select neon in the servers file (http-library=neon), I get an
error message: could not connect to server.

Here is the call stack:
svn_ra_serf__contect_run_wait
svn_ra_serf__exchange_capabilities
svn_ra_serf__open
svn_ra_open3
svn_cl__update
main

The reason for the endless loop is: serf_context_run keeps on returning
status 0 in stead of a timeout error.

I am using trunk revision 1222 of serf.

You can easily reproduce this by specifying a non-existing ip-address in
the hosts file for the server.

Regards,
Marc

-----Original Message-----
From: Neels J Hofmeyr [mailto:neels_at_elego.de]
Sent: 10 June 2009 15:01
To: Marc Haesen
Cc: dev_at_subversion.tigris.org
Subject: Re: Endless loop in handle_fetch routine of
trunk/subversion/libsvn_ra_serv/update.c

Marc Haesen wrote:
> Hi,
>
> I am experiencing lockups in the svn client (latest trunk version)
> executing the svn up command. When it happens, the client is in an
> endless loop in the handle_fetch routine of
> trunk/subversion/libsvn_ra_serv/update.c.

Hi Marc,

thanks for your report. Could you please provide lots more specific
information so we can reproduce the issue?

- which revision of trunk (the latest version constantly changes)
- what commands did you use exactly
- the exact output of svn when you used those commands

But before you do, please verify that your build is in fact clean.

1) Please remove/move away your trunk working copy, checkout and rebuild
entirely from scratch. We've been having build artefacts lately.

2) Using a self-built subversion may collide with svn libraries or
dependencies (apr, apr-util, sqlite...) installed system-wide. The only
way
that I can build and successfully run lots of different Subversions is
to
  a) uninstall the system wide subversion completely.
  b) uninstall all those system wide libraries that you checked out as a
tar
     and pass to subversion's ./configure. (If you use system-wide
installed
     libraries it's fine, just don't use system-wide and tar at the same
     time)
  c) install to e.g. $HOME/prefix (If you want only one subversion
version,
     installing system wide is fine)
The cause is libtool, accidentally loading the wrong libs with the right
binary. (I'm on ubuntu)

your efforts will be appreciated :)
~Neels

>
>
>
> The reason for the endless loop is that the serf_bucket_read function
> keeps on returning zero bytes without returning an error.
> fetch_ctx->aborted_read and fetch_ctx->delta_stream are false. The
> status that is returned is 0.
>
> Should there be no timeout in this loop that returns an error when no
> data is received within a certain time frame?
>
>
>
> The callstack is the following:
>
>
>
> handle_fetch
>
> handle_response
>
> read_from_connection
>
> process_connection
>
> serf_context_run
>
> finish_report
>
> svn_wc_crawl_revisions4
>
> svn_client__update_internal
>
> svn_client_update3
>
> svn_cl__update
>
>
>
> Regards,
>
> Marc
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2361193
Received on 2009-06-11 09:29:04 CEST

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

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