On Fri, 20 Mar 2009, John D wrote:

> Per your point you are right. The callbacks do make them thread safe. With
> that mentioned having a multithreaded applications being the key we are
> already in lock paradise and nobody wants to stay longer there.

But isn't NSS just hiding the locks from you and not completely avoiding them?
I don't know this, I've just assumed it so it would be interesting to get to
know the truth!

> As your stack trace request goes here it is. Please keep in mind that the
> symbolic version
> only points to the exact lines that induce the ssl communication:
>
> Program received signal SIGPIPE, Broken pipe.
> [Switching to Thread -1323496560 (LWP 22244)]
> 0xb7f5f410 in ?? ()
> (gdb) where
> #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?

-- 
  / daniel.haxx.se