curl / Mailing Lists / curl-library / Single Mail


Re: Access violation in Curl_hash_add

From: Ray Satiro via curl-library <>
Date: Sat, 10 Dec 2016 17:56:02 -0500

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

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));
       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.


List admin:
Received on 2016-12-10