On Fri, Nov 14, 2008 at 11:27 AM, <iamsal_at_interfree.it> wrote:

> I rewrote the code in multithreading (2 threads) so i can see
> that curl create two identical connection so the cleanup goes
> to clean all the connections.

Changing a single-threaded application that crashes into a
multi-threaded application is probably not going to make the
problem any easier to find, but I guess it never hurts to try.

> i use an application really similar to this:
> http://curl.haxx.se/lxr/source/docs/examples/multithread.c#L40
> but my appliation crashes.

If you have a libcurl-using application that crashes, that
is "really similar" to a libcurl-using example that doesn't
crash, the problem is likely not in libcurl.

Have you tried running your program inside a debugger to
see where the crash occurs, and what state the data is in
when it happens?

From the little bit you've shown so far, what I would guess
is that the server sometimes sends back a response header
(probably something other than 200/OK) but doesn't send any
data after that. In that case, your write callback never
gets called, and your chunk.memory remains NULL. If that
happens, then your call to memcpy will certainly crash.

Just because curl_easy_perform returns CURLE_OK, it doesn't
indicate that everything worked perfectly. It just means
libcurl connected to the server, and got some sort of a
response, but the response could be any number of things
besides a successful download. So you may also want to
test for something like:

 long resp;
 curl_easy_getinfo(curl_handle, CURLINFO_RESPONSE_CODE, &resp);
 if (resp != 200) {
    /* something went wrong! */
 }

But still, you should check that (chunk.memory!=NULL)
before trying to read its contents.

And again, sometimes CURLOPT_VERBOSE can really help!

- Jeff
Received on 2008-11-14