On 3/21/09, Daniel Stenberg <dan...@haxx.se> 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.
>> Typically, PR_Init is called in the primordial thread.
>>
>
> Thank you. I suspected this, but the docs page said nothing about it so I
> felt I better ask.
>
> John, is that possibly the key to your problem? curl_global_init() is
> documented to be called first, it is documented not thread-safe and it calls
> PR_Init()... If curl_global_init() isn't called, libcurl will call it by
> itself on first use of another function but you're using threads so I would
> guess you get a bad race then and thus anything can happen!
>
> --
>
> / daniel.haxx.se
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
curl_global_init(CURL_GLOBAL_ALL);
for (int l = 0; l != threadlevel; l++)
{
int opb = l + 1;
boost::thread athread(opv,opb);
activethreads++;
}
Not the case I'm afraid.
#0 0xb7f13410 in ?? ()
#1 0x9f93f668 in ?? ()
#2 0xb7a7c554 in ?? () from /usr/lib/libnspr4.so.0d
#3 0x9f93f600 in ?? ()
#4 0xb7c6d478 in send () from /lib/i686/cmov/libc.so.6
#5 0xb7a70f8e in PR_GetConnectStatus () from /usr/lib/libnspr4.so.0d
#6 0xb79c36b9 in NSSSSL_VersionCheck () from /usr/lib/libssl3.so.1d
#7 0xb79b6e85 in SSL_GetStatistics () from /usr/lib/libssl3.so.1d
#8 0xb6b37230 in ?? ()
#9 0xb6b814c8 in ?? ()
#10 0x00000017 in ?? ()
#11 0x00000000 in ?? ()
Is what I am getting even with an updated debug enabled libcurl.
Above is the output from the sigpipe error itself.
This one is caused by the same unknown issue but happens sequentially
different
as the software is doing many things at once and can break the same way
differently.
#0 0xb7a50547 in NSSSSL_VersionCheck () from /usr/lib/libssl3.so.1d
#1 0xb7a4c12d in SSL_GetStatistics () from /usr/lib/libssl3.so.1d
#2 0x940ac0e8 in ?? ()
#3 0x940d08f0 in ?? ()
#4 0x00003267 in ?? ()
#5 0x00000000 in ?? ()
Any guidance with this clearly NSS issue is of much help to me.
Thank you,
John
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
