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.
Received on 2009-04-10