Well, with the test program I obvserve that fds are not being leaked,
also I'm not getting segfaults as I previously reported, but I observe
that a huge amount of fds are beeing used when I use 10 concurrent curl
handles with the multi_socket interface, I get around 50 open fds. And I
have seen the following condition from time to time:

connect returns EINPROGRES, the socket_callback is called to register
the fd, and the call to epoll fails since the fd is not ready:

See the following trace:

socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 30
fcntl64(30, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(30, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(30, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("66.77.88.169")}, 16) = -1 EINPROGRESS (Operation now
in progress)
poll([{fd=30, events=POLLOUT}], 1, 0) = 0
gettimeofday({1175235195, 51532}, NULL) = 0
gettimeofday({1175235195, 51583}, NULL) = 0
gettimeofday({1175235195, 51640}, NULL) = 0
gettimeofday({1175235195, 51690}, NULL) = 0
poll([{fd=30, events=POLLOUT}], 1, 0) = 0
write(1, "***********\n", 12) = 12
write(1, "mycurl::socket_callback, handle:"..., 53) = 53
write(1, "handle: 0x80a16a8 url: http://bl"..., 99) = 99
write(1, "handler already installed\n", 26) = 26
write(1, "arm(30) OUT\n", 12) = 12
epoll_ctl(3, EPOLL_CTL_MOD, 30, {EPOLLOUT|EPOLLET, {u32=30, u64=30}}) =
-1 ENOENT (No such file or directory)

The following happens from 1 to 5 minutes with 10 concurrent connections
and enough urls to keep it busy. I guess it can be reproduced with the
test program adding enough urls and increasing the number of
simultaneous handles.

Regards.

On 3/28/07, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Wed, 28 Mar 2007, Pedro Larroy wrote:
>
> > Now with 7.16.2-CVS with the attached config.log neither the leak nor the
> > CLOSE_WAIT state seems to happen anymore.
>
> So is there a remaining problem then?
>
> --
> Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
>
Received on 2007-03-30