On Fri, 20 Mar 2009, John D wrote:

> We are using libcurl to to fast acting continual ssl loops using mozilla's
> NSS ssl library. This was utilized for the sake of brevity considering it
> seems the only stable implementation that is thread safe.

How so? I'm quite sure both OpenSSL and GnuTLS are as well, with the only
caveat that you need to set the mutex callbacks yourself while in the NSS case
it does it on its own.

> Our code has seen an even mix of sefaults and sigpipes by way of gdb
> testing. This often is reported as being caused by an NSS version check or
> with symbols points to the ssl related code.

Can you show us a stack trace of when this happens? Is NSS protecting itself
against SIGPIPE?

> I know this is going to immediately be responsed to by a 3rd party finger
> pointing however seeing the thread safety of ssl already gets that

We don't "point finger" regarding thread safety of ssl, but we describe what
you need to do to make the use thread-safe.

In regards to details on the SSL libs we of course point fingers to their
respective camps since the experts of those libs are not usually present here
(afaik).

> A is it possible that anyone knows how to handle an ssl generated sigpipe in
> libcurl if only as NSS has no mailing list for this type of question.

NSS has a mailing list and I noticed you already posted about this problem
there.

To me it feels like a problem with NSS' use of recv or send, but I'm not sure
about it.

> I have no idea how to handle an ssl broken pipe without access to the actual
> socket and not a curl easy setop for instance.

Hopefully there's some mechanism in the NSS API that we have missed that will
fix this problem!

-- 
  / daniel.haxx.se