curl-library
Re: cURL bug -- Segmentation Fault when timeout is 1 second
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?
Hello.
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.
http://www.c-plusplus.de/forum/viewtopic-var-p-is-1660082.html#1660082
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/libcurl.so.3
#1 0xb7cdecd1 in curl_msnprintf () from /usr/lib/libcurl.so.3
#2 0xb7ce021c in curl_mvsnprintf () from /usr/lib/libcurl.so.3
#3 0xb7ccfa75 in curl_slist_free_all () from /usr/lib/libcurl.so.3
#4 0xb7cc7e5b in ?? () from /usr/lib/libcurl.so.3
#5 0x498f25f7 in ?? ()
#6 0xb7cef461 in ?? () from /usr/lib/libcurl.so.3
#7 0xb7c0fa76 in gettimeofday () from /lib/tls/i686/cmov/libc.so.6
#8 0xb7cc73db in ?? () from /usr/lib/libcurl.so.3
#9 0xb286d7e8 in ?? ()
#10 0x00000000 in ?? ()
Regards
Daniel Marschall
>
> GaryM at Casabi
>
Received on 2009-02-08