> On May 13, 2021, at 6:10 AM, Daniel Stenberg wrote:
>
> 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?
You know … I neglected to mention before that I’m constrained to use
OS-provided curls … which in CentOS 7 means 7.29.
So yeah, this problem is already solved; our curl is just too old to have the
fix.
Yet another justification, though, for why we should build our own curl. :)
Thank you!
-FG
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
