Hi Dan, >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 > above. > 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 behavior undefined? > 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 http://curl.haxx.se/lxr/source/docs/examples/threaded-ssl.c. 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, CRYPTO_set_locking_callback((void (*)())lock_callback); 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 executed properly. Thanks for you help. San.
