On Fri, 20 Mar 2009, Daniel Stenberg wrote:

>> #0 0xb7f5f410 in ?? ()
>> #1 0xb11cf988 in ?? ()
>> #2 0xb7ad9554 in ?? () from /usr/lib/libnspr4.so.0d
>> #3 0xb11cf920 in ?? ()
>> #4 0xb7cca478 in send () from /lib/i686/cmov/libc.so.6
>> #5 0xb7acdf8e in PR_GetConnectStatus () from /usr/lib/libnspr4.so.0d
>> #6 0xb7a206b9 in NSSSSL_VersionCheck () from /usr/lib/libssl3.so.1d
>> #7 0xb7a13e85 in SSL_GetStatistics () from /usr/lib/libssl3.so.1d
>> #8 0x0ec62e10 in ?? ()
>> #9 0x0ee2e8a8 in ?? ()
>
> Can't you (re-)build libcurl with debug symbols to get a better idea about
> when during libcurl's flow the call happens?

I just want to summarize where this took us:

John brought this to the NSS mailing list where we learned a few things:

* NSS itself ignores SIPIPE after PR_Init() (more specificly the sub part
   called NSPR does it) thus getting this signal would indicate something weird
   like a bad call sequence order. PR_Init() itself is called by
   curl_global_init() and is *not* thread-safe.

* John maintains that he's doing things in the right way in libcurl, that
   means calling curl_global_init() before any threads are started.

* When John switched to using GnuTLS instead the problem went away.

* We never got any detailed stack trace with proper symbols from NSS and
   libcurl that shows exactly what was going on and how that SIGPIPE got
   generated, so I think this case is closed as far as me concerns. Without
   further feedback we can't really work on this from either end, not NSS nor
   libcurl.

Case closed.

-- 
  / daniel.haxx.se