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: Wrong connection reuse case for Share interface
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 2 Jul 2026 19:24:19 +0000
Thanks for clarification. Somehow, I missed this behavior change.
But it used to be working OK in the older libcurl versions, so it may seem like regression for folks upgrading from older versions.
And the problem can be that the order of how share is set to NULL and handle is removed can be deeply buried in some framework or 3rd party library,
which is not easy to change to work around this new limitation.
Hopefully, as you said, this case will be handled better in the future, and setting share to NULL before removing handle from the multi will close the connection rather result into UB.
Thanks!
Dmitry
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Thursday, July 2, 2026 9:20 AM
To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Cc: Dmitry Karpov <dkarpov_at_roku.com>
Subject: [EXTERNAL] Re: Wrong connection reuse case for Share interface
On Wed, 1 Jul 2026, Dmitry Karpov via curl-library wrote:
> * Run the transfer using multi interface to some point where it will
> be abandoned (i.e. application may make this decision due to lack of
> space where to write incoming data etc)
> * Set share to NULL on "abandoned" easy handle to avoid using the
> share on that transfer further and remove it from the multi handle
> (via curl_multi_remove_handle()).
Sharing was not designed to get dynamically modified during transfers. You should remove the easy handle from the multi first, then change sharing options.
The CURLOPT_SHARE man page has this wording since a couple of months back:
Warning: adding a *share* and then setting it to NULL while the transfer is
ongoing is discouraged and may lead to undefined behavior.
That said, we can of course add code to handle this specific case better.
Date: Thu, 2 Jul 2026 19:24:19 +0000
Thanks for clarification. Somehow, I missed this behavior change.
But it used to be working OK in the older libcurl versions, so it may seem like regression for folks upgrading from older versions.
And the problem can be that the order of how share is set to NULL and handle is removed can be deeply buried in some framework or 3rd party library,
which is not easy to change to work around this new limitation.
Hopefully, as you said, this case will be handled better in the future, and setting share to NULL before removing handle from the multi will close the connection rather result into UB.
Thanks!
Dmitry
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Thursday, July 2, 2026 9:20 AM
To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Cc: Dmitry Karpov <dkarpov_at_roku.com>
Subject: [EXTERNAL] Re: Wrong connection reuse case for Share interface
On Wed, 1 Jul 2026, Dmitry Karpov via curl-library wrote:
> * Run the transfer using multi interface to some point where it will
> be abandoned (i.e. application may make this decision due to lack of
> space where to write incoming data etc)
> * Set share to NULL on "abandoned" easy handle to avoid using the
> share on that transfer further and remove it from the multi handle
> (via curl_multi_remove_handle()).
Sharing was not designed to get dynamically modified during transfers. You should remove the easy handle from the multi first, then change sharing options.
The CURLOPT_SHARE man page has this wording since a couple of months back:
Warning: adding a *share* and then setting it to NULL while the transfer is
ongoing is discouraged and may lead to undefined behavior.
That said, we can of course add code to handle this specific case better.
-- / 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-07-02