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
