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@yahoo.com> To: libcurl development <curl-library@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@haxx.se> To: Alan <jkabeal-curl@yahoo.com>; libcurl development <curl-library@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

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