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
