Re: libcurl hangs in curl_multi_cleanup
Dnia 2021-06-18, o godz. 09:31:42 Daniel Stenberg napisał(a): > On Thu, 17 Jun 2021, FirefoxOS via curl-library wrote: > > > Can you help me understand what does test660 actually check? > > > The issue is easily reproducible using curl_imap_teardown_issue.c > > Then clearly test660 doesn't run the same sequence. > > Does the curl_imap_teardown_issue.c code also cause a problem if run against > an IMAP server without using TLS? > Do you mean imap://...? Yes, it does. And the callstack looks the same. -- --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: libcurl hangs in curl_multi_cleanup
Dnia 2021-06-10, o godz. 08:14:05 Daniel Stenberg napisał(a): > On Thu, 10 Jun 2021, Firefox OS via curl-library wrote: > > > Unfortunately the bug is there again. > > At least in 7.76.1 and 7.70.0. > > Particularly, curl_multi_cleanup() hangs for exactly 2 minutes. > > Please tell us the whole story. > > What do you do and when does it hang? We want to be able to reproduce. > > What curl version with what components? > Hi, The story is the same as 2 years ago, that's why I only replied to that thread. Please have a look at https://curl.se/mail/lib-2019-04/0052.html. The program curl_imap_teardown_issue.c attached there is now able to reproduce the original problem again (hung curl_multi_cleanup) but with curl library v7.76.1 shipped with Fedora 34. I also see hung curl_multi_cleanup() with cross-compiled curl library in latest version (7.77.0, not 7.70.0 - sorry), and I guess the issue is the same as in 7.76.1, although I'm not 100% sure. --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: libcurl hangs in curl_multi_cleanup
Dnia 2019-05-06, o godz. 23:59:25 Firefox OS via curl-library napisał(a): > Dnia 2019-04-21, o godz. 23:21:07 > Daniel Stenberg via curl-library napisał(a): > > > On Fri, 19 Apr 2019, Daniel Stenberg via curl-library wrote: > > > > > My proposed fix for this issue is now here: > > > > > > https://github.com/curl/curl/pull/3795 > > > > That one landed in git too and will ship in the next release. > > > > Hi, > > I've rebuilt libcurl-7.64.1 patched with just > https://github.com/curl/curl/commit/e06b8bdae6a6e552d7430c00853d18b9378eac29 > and the issue seems to be gone. > > Thanks Hi, Unfortunately the bug is there again. At least in 7.76.1 and 7.70.0. Particularly, curl_multi_cleanup() hangs for exactly 2 minutes. #0 0x77e355bf in poll () from /lib64/libc.so.6 #1 0x77f5c61e in Curl_poll () from /lib64/libcurl.so.4 #2 0x77f5c756 in Curl_socket_check () from /lib64/libcurl.so.4 #3 0x77f550de in Curl_pp_statemach () from /lib64/libcurl.so.4 #4 0x77f4bb7d in imap_disconnect.lto_priv () from /lib64/libcurl.so.4 #5 0x77f6b53f in Curl_disconnect () from /lib64/libcurl.so.4 #6 0x77f24917 in Curl_conncache_close_all_connections () from /lib64/libcurl.so.4 #7 0x77f5308b in curl_multi_cleanup () from /lib64/libcurl.so.4 #8 0x0040139a in main (argc=, argv=) at curl_imap_teardown_issue.c:89 -- --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
curl 7.75.0 fails to compile
Hi,
I got following compilation error in 7.75 release.
It was OK in curl 7.74.
The attached patch fixes the compilation problem in my case.
http.c:1963:10: error: conflicting types for ‘Curl_add_timecondition’
1963 | CURLcode Curl_add_timecondition(const struct connectdata *conn,
| ^~
In file included from urldata.h:136,
from http.c:52:
http.h:67:10: note: previous declaration of ‘Curl_add_timecondition’ was here
67 | CURLcode Curl_add_timecondition(struct Curl_easy *data,
| ^~
http.c: In function ‘Curl_http’:
http.c:3167:37: warning: passing argument 1 of ‘Curl_add_timecondition’ from
incompatible pointer type [-Wincompatible-pointer-types]
3167 | result = Curl_add_timecondition(data, );
| ^~~~
| |
| struct Curl_easy *
http.c:1963:59: note: expected ‘const struct connectdata *’ but argument is of
type ‘struct Curl_easy *’
1963 | CURLcode Curl_add_timecondition(const struct connectdata *conn,
| ~~^~~~
--
--- a/lib/http.c
+++ b/lib/http.c
@@ -1960,10 +1960,10 @@
}
#else
/* disabled */
-CURLcode Curl_add_timecondition(const struct connectdata *conn,
+CURLcode Curl_add_timecondition(struct Curl_easy *data,
struct dynbuf *req)
{
- (void)conn;
+ (void)data;
(void)req;
return CURLE_OK;
}
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Re: Build fails after upgrading from 7.72 to 7.73
Dnia 2020-10-15, o godz. 18:21:26 Jeffrey Walton napisał(a): > It looks like some sort of typo. I cannot find ssl_config_data in the > OpenSSL 1.1.x branch or the previous 1.0.x branch: > I also took a peek in the OpenSSL 0.9.8 branch, and ssl_config_data > was missing there, too. > > Maybe a different backend provides ssl_config_data. > > Jeff struct ssl_config_data is part of curl itself (lib/urldata.h), not openssl. The mentioned fields are defined there under #ifdef USE_TLS_SRP. In curl 7.72 references to these fields from lib/vtls/openssl.c were (consistently) under #ifdef USE_TLS_SRP, but in curl 7.72 it changed to #ifdef HAVE_OPENSSL_SRP. -- --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Build fails after upgrading from 7.72 to 7.73
Hi,
I tried to build curl 7.73 using following options:
./configure --disable-static --enable-shared --prefix=/usr \
--host=i686-buildroot-linux-uclibc --disable-debug \
--enable-warnings --disable-curldebug --enable-symbol-hiding \
--disable-ares --enable-silent-rules --disable-largefile \
--enable-http --disable-ftp --disable-file --disable-ldap \
--disable-ldaps --disable-rtsp --enable-proxy --disable-dict \
--disable-telnet --disable-tftp --disable-pop3 --enable-imap \
--enable-smtp --disable-gopher --disable-manual \
--disable-libcurl-option --disable-ipv6 --disable-unix-sockets \
--enable-versioned-symbols --enable-threaded-resolver \
--disable-verbose --disable-sspi --enable-crypto-auth \
--disable-ntlm-wb --disable-tls-srp --enable-cookies \
--enable-http-auth --disable-doh --disable-mime \
--disable-dateparse --disable-netrc --disable-progress-meter \
--disable-dnsshuffle \
--without-gnutls --without-wolfssl --without-bearssl \
--without-libmetalink --without-libssh2 --without-librtmp \
--without-libidn \
--with-ca-path=/etc/certs
Results:
...
checking for SRP_Calc_client_key in -lcrypto... yes
configure: built with one SSL backend
...
checking whether to enable TLS-SRP authentication... no
...
curl version: 7.73.0
SSL: enabled (OpenSSL)
...
TLS-SRP: no (--enable-tls-srp)
...
In file included from vtls/openssl.c:55:
vtls/openssl.c: In function ‘ossl_connect_step1’:
vtls/vtls.h:133:40: error: ‘struct ssl_config_data’ has no member named
‘authtype’
133 | (SSL_IS_PROXY() ? data->set.proxy_ssl.var : data->set.ssl.var)
|^
vtls/openssl.c:2475:42: note: in expansion of macro ‘SSL_SET_OPTION’
2475 | const enum CURL_TLSAUTH ssl_authtype = SSL_SET_OPTION(authtype);
| ^~
vtls/vtls.h:133:60: error: ‘struct ssl_config_data’ has no member named
‘authtype’
133 | (SSL_IS_PROXY() ? data->set.proxy_ssl.var : data->set.ssl.var)
|^
vtls/openssl.c:2475:42: note: in expansion of macro ‘SSL_SET_OPTION’
2475 | const enum CURL_TLSAUTH ssl_authtype = SSL_SET_OPTION(authtype);
| ^~
vtls/vtls.h:133:40: error: ‘struct ssl_config_data’ has no member named
‘username’
133 | (SSL_IS_PROXY() ? data->set.proxy_ssl.var : data->set.ssl.var)
|^
vtls/openssl.c:2802:33: note: in expansion of macro ‘SSL_SET_OPTION’
2802 | char * const ssl_username = SSL_SET_OPTION(username);
| ^~
vtls/vtls.h:133:60: error: ‘struct ssl_config_data’ has no member named
‘username’
133 | (SSL_IS_PROXY() ? data->set.proxy_ssl.var : data->set.ssl.var)
|^
vtls/openssl.c:2802:33: note: in expansion of macro ‘SSL_SET_OPTION’
2802 | char * const ssl_username = SSL_SET_OPTION(username);
| ^~
vtls/vtls.h:133:40: error: ‘struct ssl_config_data’ has no member named
‘password’
133 | (SSL_IS_PROXY() ? data->set.proxy_ssl.var : data->set.ssl.var)
|^
vtls/openssl.c:2810:48: note: in expansion of macro ‘SSL_SET_OPTION’
2810 | if(!SSL_CTX_set_srp_password(backend->ctx,
SSL_SET_OPTION(password))) {
|^~
vtls/vtls.h:133:60: error: ‘struct ssl_config_data’ has no member named
‘password’
133 | (SSL_IS_PROXY() ? data->set.proxy_ssl.var : data->set.ssl.var)
|^
vtls/openssl.c:2810:48: note: in expansion of macro ‘SSL_SET_OPTION’
2810 | if(!SSL_CTX_set_srp_password(backend->ctx,
SSL_SET_OPTION(password))) {
|^~
make[3]: *** [Makefile:2623: vtls/libcurl_la-openssl.lo] Błąd 1
The issue goes away if I delete "--disable-tls-srp".
Does this mean that after fixing #5865 this configure option isn't respected
anymore?
--
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Missing data fragments when custom headers set
Dnia 2019-11-24, o godz. 10:21:07 tangram67 via curl-library napisał(a): > Hi to all. > > I'm using libcurl as a receiver for MP3 radio streams. > When using custom headers in conjunction with header and body data > callbacks, some data is missing in the data callbacks. This is also > reproducable when using the following command line: > > curl --header "Icy-MetaData: 1" -sD - -o ./ndr1.mp3 > http://ndr-edge-2061.dus-lg.cdn.addradio.net/ndr/ndr1niedersachsen/hannover/mp3/128/stream.mp3 > > If you play the resulting MP3 file with some kind of media player you > can hear dropdowns caused by missing data. If you remove the custom > header, then the stream is OK. Also this behaviour is independant of the > header value, so any header string will cause the problem. > Hi Dirk, What makes you think the dropdowns are caused by missing data? You requested the server to multiplex metadata with the MP3 stream. You can't send such a stream directly to MP3 decoder. Instead, your client needs to extract "icy-metaint:" response header and demux the stream appropriately (extract the metadata instead of sending them to MP3 decoder). Otherwise you're periodically feeding the decoder with garbage. Please cross-check your results with a client which doesn't use libcurl, e.g. wget -S --header "Icy-MetaData: 1" -O ndr2.mp3 http://ndr-edge-2061.dus-lg.cdn.addradio.net/ndr/ndr1niedersachsen/hannover/mp3/128/stream.mp3 -- --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libcurl hangs in curl_multi_cleanup
Dnia 2019-04-21, o godz. 23:21:07 Daniel Stenberg via curl-library napisał(a): > On Fri, 19 Apr 2019, Daniel Stenberg via curl-library wrote: > > > My proposed fix for this issue is now here: > > > > https://github.com/curl/curl/pull/3795 > > That one landed in git too and will ship in the next release. > Hi, I've rebuilt libcurl-7.64.1 patched with just https://github.com/curl/curl/commit/e06b8bdae6a6e552d7430c00853d18b9378eac29 and the issue seems to be gone. Thanks --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
libcurl hangs in curl_multi_cleanup
Hi all
I wrote a simplified program (attached) to demonstrate a problem I'm dealing
with.
The problem is that libcurl doesn't allow the program to quit because it hangs
inside curl_multi_cleanup:
(gdb) bt
#0 0x77e463f1 in poll () from /lib64/libc.so.6
#1 0x77f58a46 in poll (__timeout=1000, __nfds=,
__fds=0x7fffdc00) at /usr/include/bits/poll2.h:41
#2 Curl_socket_check (readfd0=readfd0@entry=3, readfd1=readfd1@entry=-1,
writefd=-1, timeout_ms=, timeout_ms@entry=1000)
at ../../lib/select.c:217
#3 0x77f66347 in Curl_pp_statemach (pp=pp@entry=0x422370,
block=block@entry=true) at ../../lib/pingpong.c:112
#4 0x77f61121 in imap_block_statemach (conn=)
at ../../lib/imap.c:1365
#5 imap_disconnect (conn=0x421cc0, dead_connection=)
at ../../lib/imap.c:1624
#6 0x77f3e15d in Curl_disconnect (data=0x4175c0,
conn=conn@entry=0x421cc0, dead_connection=dead_connection@entry=false)
at ../../lib/url.c:781
#7 0x77f6e8f3 in Curl_conncache_close_all_connections (
connc=connc@entry=0x409d70) at ../../lib/conncache.c:573
#8 0x77f535d1 in curl_multi_cleanup (multi=multi@entry=0x409c60)
at ../../lib/multi.c:2244
#9 0x0040139a in main (argc=, argv=)
at curl_imap_teardown_issue.c:89
The program logs in to an imaps:// server (using CURLOPT_CONNECT_ONLY), then
enters idle mode using curl_easy_send and receives answer using curl_easy_recv.
Then sleeps for a few seconds and tries to clean up everything and quit. I
followed the order given at
https://curl.haxx.se/libcurl/c/curl_multi_cleanup.html but still
curl_multi_cleanup() doesn't exit for a long time.
The issue occurs on libcurl-7.61.1 as well as on latest release curl-7.64.1.
Am I doing something wrong, or is it a bug?
--
#include
#include
#include
#include
static const char cmd[] = "A1 IDLE\n";
static char buf[1024];
int main(int argc, char **argv)
{
CURLM *mcurl;
CURL *curl;
int mrun, sock = CURL_SOCKET_BAD;
time_t start = time(NULL);
int state = 0;
ssize_t pos = 0;
if (argc < 2) {
fprintf(stderr, "Usage: %s imaps://mailserver.com u...@mailserver.com password\n", argv[0]);
return 1;
}
assert((mcurl = curl_multi_init()));
assert((curl = curl_easy_init()));
assert(curl_easy_setopt(curl, CURLOPT_VERBOSE, 1L) == CURLE_OK);
assert(curl_easy_setopt(curl, CURLOPT_URL, argv[1]) == CURLE_OK);
if (argc > 2)
assert(curl_easy_setopt(curl, CURLOPT_USERNAME, argv[2]) == CURLE_OK);
if (argc > 3)
assert(curl_easy_setopt(curl, CURLOPT_PASSWORD, argv[3]) == CURLE_OK);
assert(curl_easy_setopt(curl, CURLOPT_CONNECT_ONLY, 1L) == CURLE_OK);
//assert(curl_easy_setopt(curl, CURLOPT_MAXCONNECTS, 1L) == CURLE_OK);
assert(curl_multi_add_handle(mcurl, curl) == CURLM_OK);
while (time(NULL) - start < 5) {
struct curl_waitfd waitfd;
assert(curl_multi_perform(mcurl, ) == CURLM_OK);
for (;;) {
int i;
struct CURLMsg *m = curl_multi_info_read(mcurl, );
if (!m)
break;
if (m->msg == CURLMSG_DONE && m->easy_handle == curl) {
assert(curl_easy_getinfo(curl, CURLINFO_ACTIVESOCKET, ) == CURLE_OK);
assert(sock != CURL_SOCKET_BAD);
}
}
if (sock >= 0) {
waitfd.events = state ? CURL_WAIT_POLLIN : CURL_WAIT_POLLOUT;
waitfd.revents = 0;
assert(curl_easy_getinfo(curl, CURLINFO_ACTIVESOCKET, ) == CURLE_OK);
waitfd.fd = sock;
}
assert(curl_multi_wait(mcurl, , sock < 0 ? 0 : 1, 5000, ) == CURLM_OK);
if (sock >= 0 && (waitfd.revents & waitfd.events)) {
size_t len = 0;
if (!state) {
assert(curl_easy_send(curl, cmd + pos, sizeof(cmd) - 1 - pos, ) == CURLE_OK);
if (len > 0)
pos += len;
else
pos = 0;
if (pos == sizeof(cmd) - 1) {
state++;
pos = 0;
}
} else if (pos < sizeof(buf)) {
assert(curl_easy_recv(curl, buf + pos, sizeof(buf) - pos, ) == CURLE_OK);
if (len > 0)
pos += len;
}
if (len <= 0)
sock = -1;
}
}
if (state) {
fwrite(buf, pos, 1, stdout);
putchar('\n');
}
assert(curl_multi_remove_handle(mcurl, curl) == CURLM_OK);
curl_easy_cleanup(curl);
curl_multi_cleanup(mcurl);
return 0;
}
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
