Re: libcurl: Hang/Crash due to CURLE_COULDNT_CONNECT(probably in curl_easy_cleanup)
Date: Fri, 10 Apr 2009 12:48:46 +0530
>And is this now using a recent libcurl version?
I have used it in version (libcurl/7.19.0).
> My issue seems to be solved after commenting the "free(pError);" as shown
> Right. You should never have added it. In fact, _nothing_ libcurl returns
> should be passed in as an argument to free() (although for a few things
> you should call curl_free()).
Thanks a lot. But I did not see any issue when the curl returned
"CURLE_OPERATION_TIMEDOUT" in the original code (where we freed constant
string returned by curl_easy_strerror()). Don't you expect the same issue to
occur which happened when curl returned "CURLE_COULDNT_CONNECT" or is the
> What made you think you have to free it in the first place?
I was just freeing all my pointers, just to avoid any memory leak. And
pError was one of them :).
Here ssl mutex callbacks did not help much, however do you still recommend
to incorporate it? (Asking this again, as I am not an expert in callbacks
and don't want to commit another blatant mistake :)).
The code runs in multi-threads, but creates separate curl handle for each
thread and does not re-use any connection as shown below,
curlRC = curl_easy_setopt(curl, CURLOPT_FRESH_CONNECT, 1);
curlRC = curl_easy_setopt(curl, CURLOPT_FORBID_REUSE ,1);
One last doubt, regarding the ssl mutex callback example shown at
This code gives error on my system as below,
"threaded-ssl.c", line 64: Error: Formal argument func of type extern "C"
void(*)(int,int,const char*,int) in call to
CRYPTO_set_locking_callback(extern "C" void(*)(int,int,const char*,int)) is
being passed void(*)().
The example has,
I have corrected as below to avoid above compilation error,
CRYPTO_set_locking_callback((void (*)(int,int,const char
*,int))lock_callback); // Is this ok ?. After this change it compiled and
Thanks for you help.
Received on 2009-04-10