The link http://curl.haxx.se/libcurl/features.html#thread states
"libcurl is designed and implemented entirely thread safe". But after
analyzed libcurl's source code and testing result, looks like it's not
thread safe in following environment:
 
OS: AIX 5.2
Compiler: xlc_r
curl/libcurl src version: 7.15.1
 
In order to simplify this issue, I'd like to ask the question directly
first to see if it is a showstopper issue, if not, I will let you know
how I am using libcurl and curl.
 
I use libcurl in multi-thread mode, By instrumenting the compiler code
and running it within dbx, we received a SIGTRAP in function
Curl_resolv, line 381, file hostip.c:
 
#ifdef HAVE_SIGSETJMP
  /* this allows us to time-out from the name resolver, as the timeout
     will generate a signal and we will siglongjmp() from that here */
  if(!data->set.no_signal && sigsetjmp(curl_jmpenv, 1)) {
    /* this is coming from a siglongjmp() */
    failf(data, "name lookup timed out");
    return CURLRESOLV_ERROR;
  }
#endif

In the same file at line 283, we found the definition of curl_jmpenv
with the following comment:

#ifdef HAVE_SIGSETJMP
/* Beware this is a global and unique instance. This is used to store
the
   return address that we can jump back to from inside a signal handler.
This
   is not thread-safe stuff. */
sigjmp_buf curl_jmpenv;
#endif

As stated in this source code, looks like libcurl is not entirely thread
safe if this part of code got compiled, obviously it got compiled in my
environment, and caused my application crashed because of violated
curl_jmpenv.
 
For example:

- Thread #1: stores its stack context to curl_jmpenv
- Thread #2: stores its stack context to curl_jmpenv (overwriting the
content of thread 1)
- Thread #1: "restores" stack context from curl_jmpenv before exiting
sigsetjmp, but it actually sets it to the value of thread2.

Could you please take an investigation asap? I am very glad to cooperate
with you to have this issue solved.

Thanks,
Eric
Received on 2006-02-09