Hey Ray,

Thank you for the review and the links. The crash is random. The crash reports are coming from our error reporting system. I have gone through our code and noticed something that might be of concern. Is it OK to do this? All calls are on the same thread:


1. Call curl_easy_init()

2. Make a couple calls curl_easy_escape()

3. Cleanup the handle from curl_easy_init() with curl_easy_cleanup()

4. Call curl_global_init()

5. Make further calls to curl_easy_init()

The first 3 steps are used to encode proxy urls that get used in steps 5 and later. I know that this violates the guidance in the thread safety guide below and I will fix that but I just wanted to confirm if this could lead to errors in curl_hash_add()?

Thanks,
Jake

From: Ray Satiro [mailto:raysatiro_at_yahoo.com]
Sent: Saturday, December 10, 2016 3:56 PM
To: Jake Fehr (jfehr) <jfehr_at_cisco.com>; libcurl development <curl-library_at_cool.haxx.se>
Subject: Re: Access violation in Curl_hash_add

On 12/9/2016 11:29 AM, Jake Fehr (jfehr) wrote:

Thank you Ray and Daniel for the quick response. Our application is multithreaded and different threads will use it (Curl) for their own purposes but the code here is isolated to a single thread (there is no sharing of curl objects).

This is the code that is using curl:

I don't see anything wrong with that code other than you are passing integers to easy_setopt and you should be passing long integers, for example:

curl_easy_setopt(curl_handle, CURLOPT_HTTPPROXYTUNNEL, 1);

should be 1L since curl_easy_setopt is a variable argument function that reads arguments by size so you should pass the option's documented type (ie use a long literal in the case above, and usually long).

also repeated patterns like this are just begging for a macro:
    if(curlcode != CURLE_OK) {
      printf("%s(): curl_easy_setopt(CURLOPT_HTTPPROXYTUNNEL) returned %d (%s)", __func__, curlcode, curl_easy_strerror(curlcode));
      curl_easy_cleanup(curl_handle);
      goto ERROUT;
    }
and I would curl_easy_cleanup(curl_handle) once in ERROUT

also what's up with this comment
// with libcurl, necessary to use http:// or https:// even though the protocol is not http

I don't see anything else wrong with this code. It is not self-contained so I can't compile it and use it to attempt to reproduce your problem though. Are you able to reproduce consistently or is it just random? I would try two things, first review our thread safety [1], see if that fixes it. Next try running just one thread and see if that fixes it. Next try a git bisect [2] to drill down when the problem first occurs. Also I would make sure you check out both a version you know is good and one you know is bad and confirm that they actually are when you build from the repo.

And for the benefit of everyone here please let us know what you find.

[1]: https://curl.haxx.se/libcurl/c/threadsafe.html
[2]: https://github.com/curl/curl/wiki/how-to-git-bisect

-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-12-14