Starting program: /usr/bin/curl -0 -k -i -H X-Transcend-Version:\ 1 -b cookies.txt -c cookies.txt -L https://xxxxxxxxxxxx/ [Thread debugging using libthread_db enabled] [New Thread 0x7fcdcfd5c7a0 (LWP 13473)] HTTP/1.0 302 Temporary moved Server: Cisco AWARE 2.0 Content-Length: 0 Cache-Control: no-cache Pragma: no-cache Connection: Close Date: Tue, 30 Sep 2008 21:47:10 GMT Location: https://yyyyyyyyyyyyy/ HTTP/1.0 302 Temporary moved Server: Cisco AWARE 2.0 Content-Length: 0 Cache-Control: no-cache Pragma: no-cache Connection: Close Date: Tue, 30 Sep 2008 21:47:11 GMT Location: /+webvpn+/index.html ^C Program received signal SIGINT, Interrupt. 0x000000372940d744 in __lll_lock_wait () from /lib64/libpthread.so.0 Current language: auto; currently asm (gdb) bt #0 0x000000372940d744 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x0000003729408f50 in _L_lock_834 () from /lib64/libpthread.so.0 #2 0x0000003729408dd0 in __pthread_mutex_lock (mutex=<value optimized out>) at pthread_mutex_lock.c:103 #3 0x0000003737c24049 in PR_Lock () from /lib64/libnspr4.so #4 0x000000386a8366e2 in Curl_nss_connect () from /usr/lib64/libcurl.so.4 #5 0x000000386a81489c in Curl_http_connect () from /usr/lib64/libcurl.so.4 #6 0x000000386a81abc2 in Curl_protocol_connect () from /usr/lib64/libcurl.so.4 #7 0x000000386a81d615 in Curl_connect () from /usr/lib64/libcurl.so.4 #8 0x000000386a828a9b in Curl_perform () from /usr/lib64/libcurl.so.4
I tried curl_easy_cleanup() and starting a new request, but still saw the deadlock. So I tried the workaround below, and now get something stranger: Will connect to https://vpntest/ Got redirect to https://vpntest/+webvpn+/index.html Will connect to https://vpntest/+webvpn+/index.html Curl error: Problem with the SSL CA cert (path? access rights?) again: if (curl_global_init(CURL_GLOBAL_SSL)) { fprintf(stderr, "Curl initialisation failed\n"); exit(1); } curl = curl_easy_init(); curl_easy_setopt(curl, CURLOPT_URL, url_buf); curl_easy_setopt(curl, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_1); curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, curl_err); curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0); curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, &curl_write_cb); curl_easy_setopt(curl, CURLOPT_WRITEDATA, &resp); curl_easy_setopt(curl, CURLOPT_COOKIEFILE, ""); /* FIXME: We'll want to teach cURL about using the TPM for this */ if (cert) curl_easy_setopt(curl, CURLOPT_SSLCERT, cert); headers = curl_slist_append(NULL, "X-Transcend-Version: 1"); curl_easy_setopt(curl, CURLOPT_HTTPHEADER, headers); curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 0); printf("Will connect to %s\n", url_buf); if (curl_easy_perform(curl)) { fprintf(stderr, "Curl error: %s\n", curl_err); curl_easy_cleanup(curl); curl_global_cleanup(); curl = NULL; return -EINVAL; } newurl = NULL; if (curl_easy_getinfo(curl, CURLINFO_REDIRECT_URL, &newurl)) printf("get redirect url failed\n"); if (newurl) { printf("Got redirect to %s\n", newurl); strncpy(url_buf, newurl, sizeof(url_buf)-1); curl_easy_cleanup(curl); curl_global_cleanup(); goto again; } curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &respcode);
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Looking at the backtrace it seems like already resolved NSS locking issue. Is the bug still present in up to date Fedora 10 (with curl-7.19.4-5.fc10)?
I can confirm that the error reported in comment #1 is gone. I can no longer attempt to reproduce the different error reported in comment #2 because my VPN client no longer uses curl. (It was necessary to use a SSL certificate from a Trusted Platform Module, and curl doesn't offer that functionality -- or even the possibility to talk HTTP of read/write functions provided by the app. So I ended up writing my own HTTP code. I'd love to ditch that :)
(In reply to comment #5) > I can confirm that the error reported in comment #1 is gone. I can no longer > attempt to reproduce the different error reported in comment #2 because my VPN > client no longer uses curl. Thanks for the summary! The problem with ca bundle path should be resolved as well. FYI there is now opened a tracking bug 501138 for bugs caused by migration to NSS.