Here is the only solution I have found so far. It is really a hack.

--- curl-7.34.0/lib/ftp.c 2013-12-16 23:02:36 -0500
+++ curl-7.34.0.vc10/lib/ftp.c 2014-02-19 17:11:28 -0500
@@ -881,7 +881,10 @@
        connect on the secondary connection */
     socks[0] = conn->sock[FIRSTSOCKET];
     socks[1] = conn->sock[SECONDARYSOCKET];
-
+ // If the SECONDARYSOCKET is not valid, grab the tempsock.
+ if(socks[1] == CURL_SOCKET_BAD) {
+ socks[1] = conn->tempsock[0];
+ }
     return GETSOCK_READSOCK(FIRSTSOCKET) |
       GETSOCK_WRITESOCK(SECONDARYSOCKET);
   }

--------------------------------------------
On Tue, 2/18/14, Alan <jkabeal-curl_at_yahoo.com> wrote:

 Subject: Re: Windows select fails with 7.34.0 and 7.35.0 using multi_perform
 To: "libcurl development" <curl-library_at_cool.haxx.se>
 Date: Tuesday, February 18, 2014, 10:25 PM
 
 I compiled the
 library and converted the test case multi_single.c to work
 with VS2010.Used
 the VS2010 debugger to step through the good 7.33.0 and the
 bad 7.34.0 to see the differences.Here
 is what I have found.7.33.0
 connect.c Curl_connecthost sets the secondary socket
 'conn->sock[1] directly, when called
 from ftp_state_pasv_resp.7.3(4,5).0
 connect.c introduced some new data in the conn structure.
 tempsock[1:0] holds the socket after calling
 Curl_connecthost and not conn->sock[1:0]
 yet.So
 if curl_multi_fdset is called after Curl_connecthost,
 conn->sock[1] will not have the passive socket yet. And
 the fdwrite socket info will have an invalid
 socket.Looks
 like it might be timing sensitive with regard to the time
 from "connecting to ...' to 'Connected to
 ...' which causes a hole when conn->sock[1] is not
 yet set with the valid socket.I
 am really not fully versed in the libcurl design, so I
 can't offer a solution. I am sure what ever solution I
 might pick would only break something else in the
 design.I
 would be happy to test any code change that anyone
 offers.Alan
 
       
  From: Alan
 <jkabeal-curl_at_yahoo.com>
  To:
  libcurl development <curl-library_at_cool.haxx.se>
  Sent: Sunday, February
 16, 2014 6:52 PM
  Subject: Re: Windows
 select fails with 7.34.0 and 7.35.0 using multi_perform
    
 Thanks for trying out
 my test case. I was hoping that it would fail for you
 also.Not
 surprising that your test worked given the differences
 between Windows and Linux sockets.
 I
 have started to do more digging into the issue. And I
 believe your option 2 is the best. Here is what I have found
 so far:I
 looked at the fd_set structures after the call to
 curl_multi_fdset.On
 the passing case (7.33.0), when connecting for the passive
 data transfer, there is one fdread and one fdwrite socket
 active.maxfd
 is set to the highest socket as shown as an integer. For my
 test, the highest is fdwrite.On
 the failing case, (7.34.0), when connecting for the passive
 data transfer, there is one fdread and one fdwrite socket
 active.However,
 the SOCKET in the fdwrite fd_array[0] is set to -1. I
 believe this is causing select to fail.Now
 on to figuring out why fdwrite fd_array[0] is not set
 correctly.
 Alan
       
  From: Daniel Stenberg
 <daniel_at_haxx.se>
 
  To: Alan
 <jkabeal-curl_at_yahoo.com>; libcurl development
 <curl-library_at_cool.haxx.se>
  Sent: Sunday, February
 16, 2014 5:26 PM
  Subject: Re: Windows
 select fails with 7.34.0 and 7.35.0 using multi_perform
    
 On
 Sat, 15 Feb 2014, Alan wrote:
 
> I have been able to reproduce the issue
 with multi-single.c
>
> System and compile info:
> Windows 7-64 pro
>
 libCurl compiled using Makefile.m32 and MinGW G++ 4.8.0
> App compiled with G++ 4.8.0 and created a
 32bit app.
>
> Here is
 the logging output from Msys: Note I have pasted the
  modified
> multi-single.c after the
 logging
  output Please help me understand what is
> going wrong. This modified multi-single.c
 works with 7.33.0 and fails with
>
 7.34.0 and 7.35.0
 
 I
 translated your test recipe into plain C and made it build
 on my 64bit
 Linux, but it works just fine
 here! :-/
 
 So, I suggest two
 ways forward for you:
 
 1 -
 one way is to bisect to find the offending single commit
 that actually
 broke this for you. This may
 or may not be useful for us to see exactly what
 code that changed that broke it.
 
 2 - if you single-step into
 the library when the curl_multi_fdset() is called
 that returns the bitset that subsequently makes
 your select() function return
 an error, and
 investigate what it does and what bits it sets and what
 values
  
 it returns etc. The function does a set of
 actions depending on the state of
 the
 individual easy handles in use.
 
 --
 
   /
 daniel.haxx.se
 
 
    
 
 -------------------------------------------------------------------
 List admin: http://cool.haxx.se/list/listinfo/curl-library
 Etiquette:  http://curl.haxx.se/mail/etiquette.html
 
    
 
 -----Inline Attachment Follows-----
 
 -------------------------------------------------------------------
 List admin: http://cool.haxx.se/list/listinfo/curl-library
 Etiquette:  http://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-02-19