curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. 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 himself.

Re: How to debug cULR multi handle timeout caused by not writing to socket

From: Yongkang Huang via curl-library <>
Date: Fri, 29 Oct 2021 18:17:13 +0000

I worked on this issue, this seems only occur when thereís multiplex on a socket with connection re-usage, you can try to disable connection reusage by CURLOPT_FORBID_REUSE, Iíll follow up in Github with a more detailed issue post soon.

Here is some known issue seems related, but the detail doesnít match exactly what I see

  * Yongkang

From: Jason Qian <>
Date: Friday, October 29, 2021 at 7:01 AM
To: libcurl development <>
Cc: Yongkang Huang <>
Subject: Re: How to debug cULR multi handle timeout caused by not writing to socket
Hi Yongkang,

I have run into the same issue as you described. Please let me know if you got solution.


On Tue, Oct 26, 2021 at 7:59 PM Yongkang Huang via curl-library <<>> wrote:
Following the previous email, I know thatís a high level description, but how could I debug with more visibility?

Thanks in advance!

From: Yongkang Huang <<>>
Date: Tuesday, October 26, 2021 at 4:57 PM
To:<> <<>>
Subject: How to debug cULR multi handle timeout caused by not writing to socket

Following the thread I sent previously, now Iím working on an application that structured as the following way

  1. A thread holds a static curl multi handle and running as the event base
  2. When thereís a user request to do a HTTP call, a easy handle would be created and passing to the thread holding the curl multi handle.
  3. The curl multi thread will add the easy handle to the multi handle, and drive the IO with the event base.
  4. Once a request finished, return the easy handle to the thread dealing with user request
This model working fine when I do the request sequentially on a single thread with user traffic, but when thereís multiple request scheduled concurrently, thereís a wired bug that the write to a socket would stuck until a timeout finished (tcpdump shows a the tcp stuck on sending the application data instead of waiting for remote ack), usually itís either the connect timeout we set to connect to proxy, or the total timeout without the connect timeout. For example if the connect timeout is 10s, and total timeout is 30, a lot of request will finished in 10 second or 20 seconds, even waiting indefinitely until the total timeout passed.


Received on 2021-10-29