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 <[email protected]>
To: libcurl development <[email protected]>
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 <[email protected]>
To: Alan <[email protected]>; libcurl development
<[email protected]>
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
