curl_multi_remove_handle callbacks - debug mode?

[Felipe Gasper via curl-library]

Hi,

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?

Thank you!

cheers,
-Felipe

p.s. More context: https://github.com/sparky/perl-Net-Curl/pull/62
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette

[Daniel Stenberg via curl-library]

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?

[Felipe Gasper via curl-library]

Post by Felipe Gasper via curl-library
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.
https://github.com/curl/curl/blob/dae382a1a1481a94b708c82d5aa9fa7253084160/lib/multi.c#L2555-L2557
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-librar