On Monday 15 October 2012 18:52:18 Joe Mason wrote:
> > From: Kamil Dudka [kdudka_at_redhat.com]
> >
> > > This warning is probably significant. There may be something wrong with
> > > the
> > > logic of the test when the socket doesn't open immediately.
> >
> > Not that I understand the logic of the test, but isn't the condition
> > inverted by mistake?
>
> It sure is! The effect is that it goes through the loop one extra time -
> the first time through the loop, it will get a new socket, print the bogus
> warning, and then run through the loop again without updating "state" -
> the next time through, no new socket will open so it will skip the warning
> and update "state". Good catch. This could have a problem in weird
> corner cases where a new socket IS opened the second time through the
> loop, but most of the time it's just an inefficiency.
>
> > I think the test terminates prematurely in certain cases. The following
> > patch makes the test-suite running on my box:
> >
> > --- a/tests/libtest/libntlmconnect.c
> > +++ b/tests/libtest/libntlmconnect.c
> > @@ -234,7 +234,7 @@ int test(char *url)
> > /* if there's no timeout and we get here on the last handle, we
> > may already have read the last part of the stream so waiting makes no
> > sense */
> > - if(num_handles == MAX_EASY_HANDLES) {
> > + if(!running && num_handles == MAX_EASY_HANDLES) {
> > break;
> > }
> > }
>
> Looks reasonable. I'm not really sure how the "running" logic of
> multi_perfom works, though.

The patch above solved the problem only partially. When running through
valgrind the test keeps hanging. I suspect the problem is that the socket
can be already closed when curl_multi_perform() returns in case no blocking
happened. Then the test ends up consuming 100% CPU by waiting for a socket
is already gone until the timeout fires up.

Kamil
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-10-16