>> 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.
>
> You're still chasing for problems in that old version?
Yes, because it is impossible to install a newer version than Debian allow.
My co-partner which owns the server, said, it is impossible to upgrade
because of the security and because many processes need curl, so it cannot
be reinstalled.
>
>> The core part of http_call() is the code from exactly the official
>> getinmemory.c example.
>
> If you use the getinmemory.c code logic, that can run in as many threads
> as you like with no problem with any recent libcurl version (at least as
> long as your process is allowed to use that many file descriptors). Unless
> you use a SSL-based protocol like https:// as then you also need to use
> the SSL library's mutex functionality.
What do you mean with the SSL-Part? What has to be other if a HTTPS-page is
called? Will the thread-safeness disappear then or whatß
>
> Can you post a full stand-alone example here that crashes for you and that
> we can use to run in our ends to help investigate?
I actually did post a full, stand-alone code that can be directly compiled
and runned, look at my post.
>
>> 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
>
> As you can see in the source code, this is a bogus stack trace. There is
> no code flow like this in libcurl and there never has been.
>
> --
>
> / daniel.haxx.se
>
Received on 2009-02-09