On Sun, 8 Feb 2009, Daniel Marschall wrote:

> 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?

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

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?

> 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