cURL / Mailing Lists / curl-library / Single Mail


Re: cURL bug -- Segmentation Fault when timeout is 1 second

From: Daniel Marschall <>
Date: Sun, 8 Feb 2009 19:36:15 +0100

>> Thank you for information. I use this source now. Alas, I still get
> the
>> memory errors. Is it possible that my debian curl version is not able
>> to
>> handle multiple http-calls at the same time (via detached threads)?
>> Note:
>> The buffer and other variables are not globals. I debug now over a
> week
>> and
>> still don't know why the procedure crashes. When I comment out the
>> http-call
>> function, there is no crash.
> If you use the getinmemory.c example *verbatim*, then you should
> not see crashes related to the write callback.
> "Handl[ing] multiple http-calls at the same time (via detached
> threads)" is a generic description, so it's hard to tell if you
> are breaking any libcurl thread rules.
> Perhaps you could share your updated write callback mechanism code
> and how you manage your multi-threaded libcurl application?


Following very, very abstracted program code should reproduce exactly the
same memory access violation I have in my real program. But this program is
independed from databases etc. As soon as libcurl gets into a
double-level-multithread environment, it crashes. When the
curl_easy_perform() part is commented out, the error doesn't appear.

The core part of http_call() is the code from exactly the official
getinmemory.c example.

All the time over, the debugger shows ALWAYS following stack (backtracking):

#0 0xb7cde88a in curl_escape () from /usr/lib/
#1 0xb7cdecd1 in curl_msnprintf () from /usr/lib/
#2 0xb7ce021c in curl_mvsnprintf () from /usr/lib/
#3 0xb7ccfa75 in curl_slist_free_all () from /usr/lib/
#4 0xb7cc7e5b in ?? () from /usr/lib/
#5 0x498f25f7 in ?? ()
#6 0xb7cef461 in ?? () from /usr/lib/
#7 0xb7c0fa76 in gettimeofday () from /lib/tls/i686/cmov/
#8 0xb7cc73db in ?? () from /usr/lib/
#9 0xb286d7e8 in ?? ()
#10 0x00000000 in ?? ()

Daniel Marschall

> GaryM at Casabi
Received on 2009-02-08