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: curl_multi_remove_handle callbacks - debug mode?

From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 13 May 2021 12:10:40 +0200 (CEST)

On Wed, 12 May 2021, Felipe Gasper via curl-library wrote:

> On a couple of occasions now I’ve chased down segfaults that it turned
> out were happening because a callback was freeing the multi.

> Is there any kind of “debug mode” in libcurl available that would
> warn, assert, or otherwise complain if something like that happens? I
> _think_ I have a fix in place that will prevent the issue moving forward,
> but that’s what I thought last time I fixed this problem. :-P
>
> If there’s not such a mode available, would that be a reasonable
> feature to add?

curl_multi_remove_handle doesn't "free the multi" though, so it sounds like
you're mixing something here.

curl_multi_cleanup() will already not accept getting called from within a
callback:

https://github.com/curl/curl/blob/dae382a1a1481a94b708c82d5aa9fa7253084160/lib/multi.c#L2555-L2557

curl_multi_remove_handle also tries to detect and avoid getting called from
within a callback:

https://github.com/curl/curl/blob/dae382a1a1481a94b708c82d5aa9fa7253084160/lib/multi.c#L740-L741

... but since you write this, I assume something makes these conditional
checks not be good enough. Can you figure out why? And if so, how would such
an additional "debug check" you speak of work that isn't already checked for?

-- 
  / daniel.haxx.se
  | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
  | https://www.wolfssl.com/contact/


-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-05-13