cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: NSSSSL - SIGPIPES & SEGFAULTS

From: John D <cononet_at_gmail.com>
Date: Fri, 20 Mar 2009 21:01:14 +0100

On 3/20/09, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> 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
>

Hey Daniel,

Yes I was able to find a secondary outlet for support with this however
seeing the reach of the issue I do not mind dealing with both lists.

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.

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 ?? ()
#10 0x00000017 in ?? ()
#11 0x00000000 in ?? ()
(gdb) list
(gdb) list
472
473 }
474
475 {
476 ** These are the first 10 lines of main() which spawns threads the
loop libcurl which passes into a segment of NSS calls.
477
478 }
479
480 */
481

Now as far as an API goes or particularly the send and receive,
I agree this surely is the cause of any broken pipe error.

The issue is that next to rebuilding NSS which I don't think should be
required,
or is that pratical for that matter,I am not able to access the needed
NSS in code to get it handled.

As the course of my research on this
has gone it is clear to me this is a neglected NSS problem and a
fully handled nonissue with curl itself. My code will handle unexpected
communication at any stage, but will NSS do so with it's 1 line of ssl
libcurl work..?

Thanks a lot,

John
Received on 2009-03-20