Could you please give a more detailed description about the problem it fixes? This makes reviewing much easier

Could you please give a more detailed description about the problem it fixes? This makes reviewing much easier

So, let's to see 'curl_multi_add_handle' error-handling tree.
In this case, 'curl_multi_cleanup(multi);' called always, even if we don't allocate new memory in this perform-iteration.
After cleanup-call the memory had freed, but the pointer still links to this dead memory..
Note, that it is not a temporary poiner - it'a pointer inside context structure

Can you please give us a recipe that reproduces this problem you want to fix like this? Or at least explain with more details how the unpatched code behaves wrongly? We run all the tests with torture tests all the time, I don't see how for example a failed alloc can trigger any problem there.

Can you please give us a recipe that reproduces this problem you want to fix like this? Or at least explain with more details how the unpatched code behaves wrongly? We run all the tests with torture tests all the time, I don't see how for example a failed alloc can trigger any problem there.

I don't have recipes for it, but it's a potential problem only if any libcurl-using software wants to continue after CURLcode handling.
You can refuse, maybe 'libcurl' not designed for very reliable software - i don't know it.

You can refuse, maybe 'libcurl' not designed for very reliable software - i don't know it.

That attitude won't help anyone. libcurl is very reliable software and as such we cannot accept code changes into the project that isn't well motivated. You propose a change here but you cannot explain to us why it is needed. We cannot merge changes that nobody sees a point with and not even the author of it can explain what it fixes.

Can you please give us a recipe that reproduces this problem you want to fix like this? Or at least explain with more details how the unpatched code behaves wrongly? We run all the tests with torture tests all the time, I don't see how for example a failed alloc can trigger any problem there.

curl_multi_add_handle doesn't fail due to lack of memory which is why torture test isn't catching this. His analysis is technically correct even though the outcome doesn't seem possible unless caused by user error, such as multi threading without sync. Anyway it's not good practice to leave it that way. @denzor200 why not just set it to NULL?

diff --git a/lib/easy.c b/lib/easy.c
index 3cb3579..988ff61 100644
--- a/lib/easy.c
+++ b/lib/easy.c
@@ -681,6 +681,7 @@ static CURLcode easy_perform(struct Curl_easy *data, bool events)
   mcode = curl_multi_add_handle(multi, data);
   if(mcode) {
     curl_multi_cleanup(multi);
+    data->multi_easy = NULL;
     if(mcode == CURLM_OUT_OF_MEMORY)
       return CURLE_OUT_OF_MEMORY;
     return CURLE_FAILED_INIT;

• data->multi_easy = NULL;

Ah yes that seems like the right defensive thing to do, even as you say it's really hard to get curl_multi_add_handle() to return an error there.

why not just set it to NULL?

I agree, a good idea

@denzor200 will you make your PR do that instead and rebase/force-push?

Thanks