cURL / Mailing Lists / curl-library / Single Mail


double free or corruption error on post with libcurl

From: Jeremy Brown <>
Date: Wed, 04 May 2005 10:18:50 -0600

I am receiving an error in my c program when I reach 10 threads at about 80,000 hits(approx 1000 per second) using libcurl against a proxy box. But the error appears to be unrelated to the hits as it has shown up earlier and later but always repeatable. I have searched the archives and the web and I could find no mention of the error or workaround. Please let me know if there is something simple I have missed in this example and sorry for the sloppy code as this was just a proof of concept at this point. The difficulty is that I can't reproduce the error against an apache webserver. I think this may be because it does not reach the same hits per second. Or it could be some crazy error path that is only being reached by my proxy. I can repeat the error on 32 and 64 bit systems hardware both running Suse Linux.
I am expecting some of the connections to fail and not complete since i am using this for a load test but the double free or connection error kills the program and I cannot retrieve any stats.
Suse 9.3 64 bit hardware 3.7 GHZ cpu, 2 GB ram,
Linux st175 #1 SMP Wed Mar 23 21:52:37 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux
libcurl 7.13.0-5 x86_64
glibc 2.3.4-23 x86_64
zlib 1.2.2-5 x86_64
openssl 0.9.7e-3 x86_64
Here is the program running and the error I receive.
st175:/stnetall/loader # ./test 2
all threads created***************
Creating thread 0
sCreating thread 5
sCreating thread 4
sCreating thread 1
Creating thread 2
sCreating thread 3
ssCreating thread 7
Creating thread 8
Creating thread 9
sssCreating thread 6
*** glibc detected *** double free or corruption (!prev): 0x00000000005345b0 ***
sAborted (core dumped)
st175:/stnetall/loader # ll
 Here is my trace of the error from gdb.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib64/
Loaded symbols for /usr/lib64/
Reading symbols from /usr/lib64/
Loaded symbols for /usr/lib64/
Reading symbols from /usr/lib64/
Loaded symbols for /usr/lib64/
Reading symbols from /lib64/
Loaded symbols for /lib64/
Reading symbols from /lib64/
Loaded symbols for /lib64/
Reading symbols from /lib64/tls/
Loaded symbols for /lib64/tls/
Reading symbols from /lib64/tls/
Loaded symbols for /lib64/tls/
Reading symbols from /lib64/
Loaded symbols for /lib64/
#0 0x00002aaaab3b6e79 in raise () from /lib64/tls/
(gdb) where
#0 0x00002aaaab3b6e79 in raise () from /lib64/tls/
#1 0x00002aaaab3b848f in abort () from /lib64/tls/
#2 0x00002aaaab3eb5d3 in __fsetlocking () from /lib64/tls/
#3 0x00002aaaab3f0153 in malloc_usable_size () from /lib64/tls/
#4 0x00002aaaab3f18a7 in free () from /lib64/tls/
#5 0x00002aaaaaee8f69 in CRYPTO_free () from /usr/lib64/
#6 0x00002aaaaae905ab in ERR_STATE_free () from /usr/lib64/
#7 0x00002aaaaae90af5 in ERR_get_state () from /usr/lib64/
#8 0x00002aaaaae90fe1 in ERR_put_error () from /usr/lib64/
#9 0x00002aaaaad12590 in SSL_CTX_new () from /usr/lib64/
#10 0x00002aaaaabdd36d in Curl_SSLConnect () from /usr/lib64/
#11 0x00002aaaaabd232a in Curl_http_connect () from /usr/lib64/
#12 0x00002aaaaabd6aec in Curl_protocol_connect () from /usr/lib64/
#13 0x00002aaaaabd76e7 in Curl_connect () from /usr/lib64/
#14 0x00002aaaaabe2bfa in Curl_follow () from /usr/lib64/
#15 0x00002aaaaabe4c5e in Curl_perform () from /usr/lib64/
#16 0x00002aaaaabe53f7 in curl_easy_perform () from /usr/lib64/
#17 0x0000000000401336 in child_create ()
#18 0x00002aaaab27a84f in pthread_create () from /lib64/tls/
#19 0x00002aaaab442703 in clone () from /lib64/tls/
#20 0x0000000000000000 in ?? ()
#21 0x0000000000000000 in ?? ()
If there is a configuration change that I could make and avoid this issue that would be great.
Let me explain the sequence of the transaction.
I log into a page and post the data and then I am redirected twice to the actual page on the backend webserver. One of the redirections is ssl so this is where the path is getting reach by the proxy. The proxy does help with the caching and data on the webserver but I have that portion disabled for now. The authentication is provided to me through a cookie so then I continue the connection and make 10 additional requests to different pages through the proxy to mimic real world usage.
Here is my curl configuration and I have included my entire code as an attachment in case that helps to clarify anything.
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, WriteMemoryCallback);
curl_easy_setopt(curl, CURLOPT_WRITEDATA, (void *)&chunk);
curl_easy_setopt(curl, CURLOPT_USERAGENT, libcurl-agent/1.0);
curl_easy_setopt(curl, CURLOPT_COOKIEFILE, ); //keep cookies in memorycurl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0); //don't verify peer against cert
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0); //don't verify host against cert
curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1); //bounce through login to next page
curl_easy_setopt(curl, CURLOPT_FORBID_REUSE, 1); //mimic real world use
curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1); //disable signals to use with threads
curl_easy_setopt(curl, CURLOPT_POSTFIELDS, data);
curl_easy_setopt(curl, CURLOPT_URL,;
ftime(&t1); //start timing
res = curl_easy_perform(curl);
ftime(&t2); //stop timing
char * url; //url to verify the connection worked
long respcode; //response code of the http transaction
long redirect; //number of redirects after we connect
char *ics =ICSLogin; //string to parse against to make sure it was successful
curl_easy_getinfo(curl,CURLINFO_EFFECTIVE_URL, &url); //grabbing it from curl
curl_easy_getinfo(curl,CURLINFO_RESPONSE_CODE, &respcode);// grabbing it from curl
curl_easy_getinfo(curl,CURLINFO_REDIRECT_COUNT, &redirect); //grabbing it from
I have 2 methods that run within the program and one does it in a single thread and the other runs it through multiple threads and this is the part that is having the error.
Here is how I compile it.
 gcc example.c `curl-config --libs` -lpthread -o example
And finally here is how I run it.
./example 2
I really would like to use the libcurl library and hope to put some effort back into the project. But I won't have the ability to use it unless I can get past this bug.

  • application/octet-stream attachment: example.c
Received on 2005-05-04