On 3/21/09, John D <cono...@gmail.com> wrote: > > > > 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 > >
I am happy to provide any specific source code you need but debug wise it is not very graphic beyond that. I am building c++ with: gcc main.cpp -o ../main -O0 -g -lcurl -lboost_thread -lboost_date_time -lboost_regex onto debian etch. Curl is: curl 7.19.4 (i686-pc-linux-gnu) libcurl/7.19.4 NSS/3.12.2.0 libidn/0.6.5 Protocols: tftp ftp telnet dict http file https ftps Features: Debug IDN IPv6 Largefile SSL The problem is vanished with removal of the s after http so to believe this is anything but a problem in curl/nss is odd. I just want it to not terminate my app when the connection dies. Thanks for everyones help with this matter thus far! John
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
