On Mar 20, 9:59 pm, ksreedha...@gmail.com wrote:
> Hello,
>
> I am using JSS 4.2.5, NSS 3.11.4 and NSPR 4.6.4
>
> Many times, my Java Server crashes with the following error.
>
> Assertion failure: 0 == rv, at ../../../../../nsprpub/pr/src/pthreads/
> ptsynch.c:207
>
> Is there any solution to this
Hello,
I am using JSS 4.2.5, NSS 3.11.4 and NSPR 4.6.4
Many times, my Java Server crashes with the following error.
Assertion failure: 0 == rv, at ../../../../../nsprpub/pr/src/pthreads/
ptsynch.c:207
Is there any solution to this.
Thanks,
Sreedhar
--
dev-tech-crypto mailing list
dev-tech-cry
On 3/21/09, Wan-Teh Chang wrote:
>
> It is an application's responsibility to call sigaction to ignore
> SIGPIPE. You can do that with the following code:
>
>#include
>
>struct sigaction sigact;
>sigact.sa_handler = SIG_IGN;
>sigemptyset(&sigact.sa_mask);
>sigact.sa_flags = 0
It is an application's responsibility to call sigaction to ignore
SIGPIPE. You can do that with the following code:
#include
struct sigaction sigact;
sigact.sa_handler = SIG_IGN;
sigemptyset(&sigact.sa_mask);
sigact.sa_flags = 0;
sigaction(SIGPIPE, &sigact, NULL);
But y
On 3/21/09, John D wrote:
>
>
>
> On 3/21/09, Daniel Stenberg wrote:
>>
>> On Fri, 20 Mar 2009, Julien R Pierre - Sun Microsystems wrote:
>>
>> NSS team: Is PR_Init() thread-safe?
>>>
>>> No, it is not thread-safe by definition, and must be called and completed
>>> before any other call to
On 3/21/09, Daniel Stenberg wrote:
>
> On Fri, 20 Mar 2009, Julien R Pierre - Sun Microsystems wrote:
>
> NSS team: Is PR_Init() thread-safe?
>>>
>>
>> No, it is not thread-safe by definition, and must be called and completed
>> before any other call to NSPR functions are made in any other thread
On Fri, 20 Mar 2009, Julien R Pierre - Sun Microsystems wrote:
NSS team: Is PR_Init() thread-safe?
No, it is not thread-safe by definition, and must be called and completed
before any other call to NSPR functions are made in any other thread.
Typically, PR_Init is called in the primordial th
Daniel,
Daniel Stenberg wrote:
NSS team: Is PR_Init() thread-safe?
No, it is not thread-safe by definition, and must be called and
completed before any other call to NSPR functions are made in any other
thread. Typically, PR_Init is called in the primordial thread.
--
dev-tech-crypto mail
On Fri, 20 Mar 2009, Wan-Teh Chang wrote:
I didn't mean that SIGPIPE is ignored only during NSPR initialization. I
meant that NSPR's initialization function calls sigaction to ignore SIGPIPE.
Oh, well that might just've been me being thick sorry. Still I read you now
loud and clear, thanks!
On Fri, 20 Mar 2009, John D wrote:
Each thread created, will call a function that runs a curl easy setopt
operation.
John: Do you call the curl_global_init() before you start any threads and use
libcurl? Can you get some further symbols in the stack trace to help me/us
with seeing who calls
On Fri, Mar 20, 2009 at 3:42 PM, Daniel Stenberg wrote:
> On Fri, 20 Mar 2009, Wan-Teh Chang wrote:
>
>> But I agree that SIGPIPE is an exception. This is why NSPR (a depenency
>> of NSS) calls sigaction() to ignore SIGPIPE during initialization. Note
>> that this is done for self protection, ra
On 3/20/09, Daniel Stenberg wrote:
>
> On Fri, 20 Mar 2009, Wan-Teh Chang wrote:
>
> But I agree that SIGPIPE is an exception. This is why NSPR (a depenency of
>> NSS) calls sigaction() to ignore SIGPIPE during initialization. Note that
>> this is done for self protection, rather than as a docum
On Fri, 20 Mar 2009, Wan-Teh Chang wrote:
But I agree that SIGPIPE is an exception. This is why NSPR (a depenency of
NSS) calls sigaction() to ignore SIGPIPE during initialization. Note that
this is done for self protection, rather than as a documented service to the
NSPR client.
But doesn
On 3/20/09, Wan-Teh Chang wrote:
>
> Nelson's point is that signal handlers are process-wide
> properties, and it is inappropriate for a library to change
> a process-wide property.
>
> But I agree that SIGPIPE is an exception. This is why
> NSPR (a depenency of NSS) calls sigaction() to ignore
>
Nelson's point is that signal handlers are process-wide
properties, and it is inappropriate for a library to change
a process-wide property.
But I agree that SIGPIPE is an exception. This is why
NSPR (a depenency of NSS) calls sigaction() to ignore
SIGPIPE during initialization. Note that this i
'since you obviously shouldn't have different PKI UIs for signatures
and authentication'? What crack are you smoking?
In the Real World, we have a different UI for authentication -- the
principal presenting an ID card -- than the UI for signatures -- a
piece of paper, a pen, and a unique mark mad
On 3/20/09, Daniel Stenberg wrote:
>
> On Fri, 20 Mar 2009, Nelson B Bolyard wrote:
>
> It would be inappropriate for NSS to defeat sigpipe's signal handler. The
>> handling of that signal is the responsibility of the application, or code at
>> a higher level than NSS. Perhaps it would be appropr
On Fri, 20 Mar 2009, Nelson B Bolyard wrote:
It would be inappropriate for NSS to defeat sigpipe's signal handler. The
handling of that signal is the responsibility of the application, or code at
a higher level than NSS. Perhaps it would be appropriate for libcurl to do
that.
SIGPIPE is a s
On 3/20/09, Nelson B Bolyard wrote:
>
> John D wrote, On 2009-03-20 11:30:
> > This is an issue involving sigfaults caused by broken pipes when using
> > fast moving multithreaded libcurl NSS. The issue is that I am unaware of
> > how to properly implement the correct signal handler or even to ign
John D wrote, On 2009-03-20 11:30:
> This is an issue involving sigfaults caused by broken pipes when using
> fast moving multithreaded libcurl NSS. The issue is that I am unaware of
> how to properly implement the correct signal handler or even to ignore
> the sigpipe and carry forward. My own co
dave davesons wrote, On 2009-03-20 10:18:
> Dear all,
>
> I have configure a reverse proxy with client certificate validation.
>
> When accessing the site using firefox, firefox first asks the user to
> select the certificate to authenticate as it should do. After this first
> authentication, how
Good day
This is an issue involving sigfaults caused by broken pipes when using fast
moving multithreaded libcurl NSS.
The issue is that I am unaware of how to properly implement the correct
signal handler or even to
ignore the sigpipe and carry forward. My own code will correct for a sigpipe
prov
>This is a stupid comment.
Pardon me. I just don't agree with the majority of this list since
many governments and banks in the EU are working in another
direction. This may be due to ignorance but I insists that there
is a problem having *two* competing session mechanisms in
web-apps; one [IMO]
David Stutzman wrote:
I'm in the process of porting over certificate path building code from
using Sun's API to using JSS as we are gradually migrating all of our
crypto over to JSS/NSS. I'm running some testing with
CryptoManager.buildCertificateChain(X509Certificate leaf).
If I grab a cert o
Dear all,
I have configure a reverse proxy with client certificate validation.
When accessing the site using firefox, firefox first asks the user to select
the certificate to authenticate as it should do. After this first
authentication, however, the user is asked again to choose the certificate
On Mar 20, 3:09 pm, Nelson B Bolyard wrote:
> arungene...@gmail.com wrote, On 2009-03-20 02:46:
>
> > I need to fetch the server certificate from an authenticated SSL
> > session in firefox. I have some amount of experience in XPCOM and NSS.
> > Just thought that NSS might help me in this and t
arungene...@gmail.com wrote, On 2009-03-20 02:46:
>I need to fetch the server certificate from an authenticated SSL
> session in firefox. I have some amount of experience in XPCOM and NSS.
> Just thought that NSS might help me in this and the following
> functions would be of use to me:
>
> C
Hi all,
I need to fetch the server certificate from an authenticated SSL
session in firefox. I have some amount of experience in XPCOM and NSS.
Just thought that NSS might help me in this and the following
functions would be of use to me:
CERTCertificate *SSL_PeerCertificate(PRFileDesc *fd)
CE
This is a stupid comment.
There are many people who think differently; I, for one, think that
server-auth is the *worse* part of TLS (because there's no branding of
what CA is responsible for the certification, there's no way to
identify when a session is re-used versus renegotiated, there's no wa
This is a stupid discussion.
Authentication schemes in general begin with authenticating the user.
How long the authentication should be considered as valid is
not something the client-end has anything to do with unless it
has gotten some kind of expiration data from the server.
It seems pretty c
On Thu, Mar 19, 2009 at 11:57 PM, Nelson B Bolyard wrote:
> Kyle Hamilton wrote, On 2009-03-19 23:07:
>
>> My reason for the conservative time suggestions is because that's what
>> banks tend to use (my bank times me out after 15 minutes of
>> inactivity, as does my phone company, and my electric
31 matches
Mail list logo
