Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: curl_easy_perform hangs in poll
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 5 Jun 2026 10:13:00 +0200 (CEST)
On Thu, 4 Jun 2026, Wyatt Ayers via curl-library wrote:
> I'm looking into an issue I am observing when running curl_easy_perform in a
> loop. After some amount of iterations, the program becomes stuck inside of
> poll.
That's curl waiting for more data to arrive.
> I've so far tested this with an FTP server via vsftpd v2.3.4 using curl
> v8.20. I tested on a fedora linux machine I initially thought this was
> related to my use of CURLOPT_FORBID_REUSE = 1, but I reproduced this
> behavior using CURLOPT_FRESH_CONNECT = 1 instead (i.e. FRESH_CONNECT = 1,
> FORBID_REUSE = 0).
The only connection FTP transfers can reuse is the control connection and that
is not what makes the data transfer, so it seems unlikely to make a difference
here. It is your data transfer connection that seems to stall.
> I can't say for certain whether or not this is a bug with my ancient FTP
> server. I can get around the hang by using a nonzero CURLOPT_TIMEOUT, though
> this is not addressing the root cause.
Wiresharking the network could tell you if the server sent the whole data
chunk and closed the connection correctly: if it did, then it is a curl
problem. Otherwise it is a server problem. But nobody else has reported such a
problem with curl so that would surprise me.
> I've included the source of a simple C program to reproduce this and a
> logfile produced with CURLOPT_VERBOSE. After a while of being in this state,
> I observe with netstat that the client machine has a socket to port 21 on
> the server machine that is in a CLOSE_WAIT state.
Port 21 is the control connection, over which curl wants the final
confirmation once the transfer is done so if that is closed, that's a good
sign something is off. curl certainly does not close that connection until
after the transfer is completed.
> Is this a problem seen elsewhere?
Not to my knowledge.
> I'm curious if this is a misuse of the curl_easy API
I couldn't see any obvious problems (apart from you not insisting on the
setopt args to be 'long' but I don't think that's the problem here).
> if I ought to use the curl_multi API for this "many repeat transfers" task.
You don't have to, but you can.
Date: Fri, 5 Jun 2026 10:13:00 +0200 (CEST)
On Thu, 4 Jun 2026, Wyatt Ayers via curl-library wrote:
> I'm looking into an issue I am observing when running curl_easy_perform in a
> loop. After some amount of iterations, the program becomes stuck inside of
> poll.
That's curl waiting for more data to arrive.
> I've so far tested this with an FTP server via vsftpd v2.3.4 using curl
> v8.20. I tested on a fedora linux machine I initially thought this was
> related to my use of CURLOPT_FORBID_REUSE = 1, but I reproduced this
> behavior using CURLOPT_FRESH_CONNECT = 1 instead (i.e. FRESH_CONNECT = 1,
> FORBID_REUSE = 0).
The only connection FTP transfers can reuse is the control connection and that
is not what makes the data transfer, so it seems unlikely to make a difference
here. It is your data transfer connection that seems to stall.
> I can't say for certain whether or not this is a bug with my ancient FTP
> server. I can get around the hang by using a nonzero CURLOPT_TIMEOUT, though
> this is not addressing the root cause.
Wiresharking the network could tell you if the server sent the whole data
chunk and closed the connection correctly: if it did, then it is a curl
problem. Otherwise it is a server problem. But nobody else has reported such a
problem with curl so that would surprise me.
> I've included the source of a simple C program to reproduce this and a
> logfile produced with CURLOPT_VERBOSE. After a while of being in this state,
> I observe with netstat that the client machine has a socket to port 21 on
> the server machine that is in a CLOSE_WAIT state.
Port 21 is the control connection, over which curl wants the final
confirmation once the transfer is done so if that is closed, that's a good
sign something is off. curl certainly does not close that connection until
after the transfer is completed.
> Is this a problem seen elsewhere?
Not to my knowledge.
> I'm curious if this is a misuse of the curl_easy API
I couldn't see any obvious problems (apart from you not insisting on the
setopt args to be 'long' but I don't think that's the problem here).
> if I ought to use the curl_multi API for this "many repeat transfers" task.
You don't have to, but you can.
-- / daniel.haxx.se || https://rock-solid.curl.dev -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-06-05