[darcs-devel] [issue1368] Another possible bug in URL.waitNextUrl: curl_multi_perform() - no running handles

[Eric Kow]

Hi, Zooko, Dmitry, Trent: news!

Stelian: thanks for the below.  We may *finally* be able to start making
progress on this with the details you've provided.

One more question: is this intermittent or systematic?  If it's systematic,
maybe I should not assume you have the same bug here, and re-open issue1808.

requests for Zooko
------------------
1. Please have a look at the --debug-http output and Stelian's guess below.
   Do they ring any bells?

2. Could you configure your build slave (marked as Ubuntu Gutsy at the time
   of this filing) to use darcs get --debug-http?

  darcs get --verbose --partial --repo-name build http://allmydata.org/ source/tahoe/server-hashedformat

comments for Dmitry, Trent
--------------------------
Hi guys, we're quickly entering over-Eric's-head territory (in all its
vastness).

Trent: I suppose this is still very different from issue1770 (particularly
       since you believe pipelining is not involved), but I'm hoping this gives
       some ideas of a common pattern regard curl

Dmitry: If you have a moment, any ideas?

On Fri, Apr 02, 2010 at 15:20:26 +0200, Stelian Ionescu wrote:
> Built using the Gentoo port. The build script is:
> http://sources.gentoo.org/viewcvs.py/*checkout*/gentoo-x86/dev-vcs/darcs/darcs-2.4.ebuild

Thanks!  This is a nice step forward because we've determined that you have
pipelining enabled (I think)

> net-misc/curl-7.20.0-r2 (Gentoo)

And that by rights your libcurl should be non-buggy (unless there's another
bug we don't know about)
 
> >  - if pipelining is enabled
> 
> How do I find that out ?

Some background: if you cabal install darcs with no flags, you get a version of
Darcs where pipelining has to be explicitly enabled on runtime; however if you
pass in -fcurl-pipelining, then the default changes (so that you have to
explicitly *disable* it on runtime).  In the future, when Cabal ticket
http://hackage.haskell.org/trac/hackage/ticket/342 is fixed, we will automatically
set -fcurl-pipelining depending on whether your libcurl is advanced enough to
avoid a pipelining bug with HTTP proxies (>= 7.19.1, I think).

Anyway, your Gentoo ebuild file seems to indicate pipelining is enabled by default
dd

src_configure() {
        # Use curl for net stuff to avoid strict version dep on HTTP and network

        cabal_src_configure \
                --flags=curl \
                --flags=-http \
                --flags=curl-pipelining \
                --flags=color \
                --flags=terminfo \
                --flags=mmap
}

> 
> tmp $ darcs get --debug-http http://www.foldr.org/~michaelw/projects/redshank
> * About to connect() to www.foldr.org port 80 (#0)
> *   Trying 2001:470:1f0b:15ba::1... * Failed to connect to 2001:470:1f0b:15ba::1: Network is unreachable
> * Success
> * couldn't connect to host
> * Expire cleared
> * Closing connection #0
> * About to connect() to www.foldr.org port 80 (#0)
> *   Trying 2001:470:1f0b:15ba::1... * Failed to connect to 2001:470:1f0b:15ba::1: Network is unreachable
> * Success
> * couldn't connect to host
> * Expire cleared
> * Closing connection #0
> darcs: bug at src/URL.hs:246 compiled Mar 31 2010 22:25:30
> Another possible bug in URL.waitNextUrl:  curl_multi_perform() - no running handles
> See http://wiki.darcs.net/index.html/BugTrackerHowto for help on bug reporting.
> withSignalsHandled: Interrupted!                                              
> 
> 
> As a first guess I'd say that this is a bug in curl because I've seen it
> in git too(oh, the irony): my network interface has a link-local
> auto-configured IPv6 address but since my ISP uses IPv4 I have no IPv6
> gateway to the internet, yet curl tries to connect to the IPv6 address
> of the remote host without falling back to the IPv4 address
> My current workaround is to add the remote hosts's IPv4 address to
> my /etc/hosts

This is interesting.  Maybe if it's a curl bug that's triggering this
instance of the problem, and if other instances are not related to this
problem, fixing the curl bug will also solve them by coincidence.

But let's dig around for some more information first.

Do you have any of the skills needed to boil this down into some sort
of example for the curl guys?

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-devel/attachments/20100402/052cf9b9/attachment.pgp>