Crash in Curl_disconnect
Hello, We are using the curl library in Asterisk (Voip stuff) in order to make some http requests. We have noticed that the library crashes when multiple requests are sent to a ip that gives a request timed out response. Our application crashes in the curl library: (gdb) bt #0 0x003e8ce30265 in raise () from /lib64/libc.so.6 #1 0x003e8ce31d10 in abort () from /lib64/libc.so.6 #2 0x003e8ce6a84b in __libc_message () from /lib64/libc.so.6 #3 0x003e8ce7230f in _int_free () from /lib64/libc.so.6 #4 0x003e8ce7276b in free () from /lib64/libc.so.6 #5 0x00314bc18c38 in Curl_disconnect (conn=0x2aaacc3caea0) at url.c:1656 #6 0x00314bc2b038 in multi_runsingle (multi=0x2aaac800d5d0, easy=0x2aaacc2388c0) at multi.c:741 #7 0x00314bc2b402 in curl_multi_perform (multi_handle=0x2aaac800d5d0, running_handles=0x442bc09c) at multi.c:953 #8 0x2aaabfbe5a3f in RequestMultiCurl (data1=0x0, data2=0x0) at curl_service.c:293 #9 0x2aaabfbe93d2 in workerService (queue=0x2aaac800d410) at data_queue.c:183 #10 0x003e8da0673d in start_thread () from /lib64/libpthread.so.0 #11 0x003e8ced3f6d in clone () from /lib64/libc.so.6 I'm using this curl version curl-7.15.5-9.el5_6.3 (comes with Centos 5.6). Can anyone help me understand what the problem is here? Thanks --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Crash in Curl_disconnect
On Thu, 25 Aug 2011, Giany wrote: I'm using this curl version curl-7.15.5-9.el5_6.3 This says it all and I'm afraid I have absolutely *zero* motivation to help you track problems in a 5 year old release. We've done over 700 documented bug fixes since then. -- / daniel.haxx.se--- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Crash in Curl_disconnect
Thank you for your response. Though I would expected to see if there is a way to isolate this from my application not in a 5 year old version release that most likely won't be ever updated in Linux repos. From: Daniel Stenberg dan...@haxx.se To: Giany giany...@yahoo.com; libcurl development curl-library@cool.haxx.se Sent: Friday, August 26, 2011 10:07 AM Subject: Re: Crash in Curl_disconnect On Thu, 25 Aug 2011, Giany wrote: I'm using this curl version curl-7.15.5-9.el5_6.3 This says it all and I'm afraid I have absolutely *zero* motivation to help you track problems in a 5 year old release. We've done over 700 documented bug fixes since then. -- / daniel.haxx.se--- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Crash in Curl_disconnect
On Fri, Aug 26, 2011 at 12:25:56AM -0700, Giany wrote: Thank you for your response. Though I would expected to see if there is a way to isolate this from my application not in a 5 year old version release that most likely won't be ever updated in Linux repos. It's almost trivial to build libcurl from source and link your application against it. Why not give it a try and see if the latest version fixes this issue? If not, then you will have some motivated developers here willing to work with you to fix it! Dan --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: RE: RE: RE: RE: Linker errors when statically compiled linking libcurl+openssl to my project
Steve Holme wrote: Mmmm very strange. I must admit I don't include SSH or RTMP support (at the moment) when I build libcurl here. I use Visual Studio (and have solution and project files for .NET 2003 (v7.1), 2005 (v8.0), 2008 (v9.0) and 2010 (v10.0)) and have them configured to build against OpenSSL (as a DLL rather than statically) and to include NTLM support. Are you building RTMP yourself, or do you have a pre-built version? I didn't build RTMP, seems that some of libs I included uses it Steve Holme wrote: Visual Studio uses a 2 pass linker. gnu-ld does not. The OP may have to reorder the libs in the link-command. -lws2_32 (missing htonl@4 etc.) should come after all other libs referring to those functions. g++ -DCURL_STATICLIB -DUSE_LIBSSH2 -DHAVE_LIBSSH2 -DCURL_DISABLE_LDAP -DHAVE_LIBSSH2_H -DLIBSSH2_WIN32 -DLIBSSH2_LIBRARY -DUSE_SSLEAY -O0 -g3 -Wall -c -fmessage-length=0 -osrc\CURLDown.o ..\src\CURLDown.cpp g++ -L../lib -oCURLDown.exe src\CURLDown.o -lcurl -lcrypto -lwinmm -lgdi32 -lwldap32 -leay32 -lidn -lrtmp -lssh2 -lz -lssl32 -lssl -lws2_32 Now I get only one error!! ../lib/librtmp.a(rtmp.o):rtmp.c:(.text+0xb45): undefined reference to `timeGetTime@0' --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: RE: RE: RE: RE: Linker errors when statically compiled linking libcurl+openssl to my project
g++ -DCURL_STATICLIB -DUSE_LIBSSH2 -DHAVE_LIBSSH2 -DCURL_DISABLE_LDAP -DHAVE_LIBSSH2_H -DLIBSSH2_WIN32 -DLIBSSH2_LIBRARY -DUSE_SSLEAY -O0 -g3 -Wall -c -fmessage-length=0 -osrc\CURLDown.o ..\src\CURLDown.cpp g++ -L../lib -oCURLDown.exe src\CURLDown.o -lcurl -lcrypto -lgdi32 -lwldap32 -leay32 -lidn -lrtmp -lssh2 -lz -lssl32 -lssl -lws2_32 -lwinmm It built without errors!! But when I ran it's just terminated, just like there - http://curl.haxx.se/mail/lib-2011-08/0161.html And dependency walkers says that IESHIMS.DLL, LIBIDN-11.DLL and LIBSSL32 is missing --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
busy loops in tests 502, 555, and 573
Hi,
I spotted that tests 502, 555, and 573 do not call select() when looping
around curl_multi_perform(). Is that intentionally?
We have been observing random timout events on 555 and 573 when running
through valgrind on our overloaded virtualized Fedora build hosts. Adding
select() to those tests seems to solve (or at least suppress) the problem.
A tentative patch is attached.
Kamil
From d5952e46bd2e5f02a2be952b0a0b65324e376596 Mon Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Fri, 26 Aug 2011 11:10:58 +0200
Subject: [PATCH] tests: break busy loops in tests 502, 555, and 573
---
tests/libtest/lib502.c | 20
tests/libtest/lib555.c | 20
tests/libtest/lib573.c | 20
3 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/tests/libtest/lib502.c b/tests/libtest/lib502.c
index 9ade12a..d936a44 100644
--- a/tests/libtest/lib502.c
+++ b/tests/libtest/lib502.c
@@ -73,6 +73,10 @@ int test(char *URL)
mp_start = tutil_tvnow();
while (running) {
+static struct timeval timeout = /* 100 ms */ { 0, 10L };
+fd_set fdread, fdwrite, fdexcep;
+int maxfd = -1;
+
res = (int)curl_multi_perform(m, running);
if (tutil_tvdiff(tutil_tvnow(), mp_start)
MULTI_PERFORM_HANG_TIMEOUT) {
@@ -83,6 +87,22 @@ int test(char *URL)
fprintf(stderr, nothing left running.\n);
break;
}
+
+FD_ZERO(fdread);
+FD_ZERO(fdwrite);
+FD_ZERO(fdexcep);
+curl_multi_fdset(m, fdread, fdwrite, fdexcep, maxfd);
+
+/* In a real-world program you OF COURSE check the return code of the
+ function calls. On success, the value of maxfd is guaranteed to be
+ greater or equal than -1. We call select(maxfd + 1, ...), specially in
+ case of (maxfd == -1), we call select(0, ...), which is basically equal
+ to sleep. */
+
+if (select(maxfd + 1, fdread, fdwrite, fdexcep, timeout) == -1) {
+ res = ~CURLM_OK;
+ break;
+}
}
if (mp_timedout) {
diff --git a/tests/libtest/lib555.c b/tests/libtest/lib555.c
index c675015..5d10771 100644
--- a/tests/libtest/lib555.c
+++ b/tests/libtest/lib555.c
@@ -135,6 +135,10 @@ int test(char *URL)
mp_start = tutil_tvnow();
while (running) {
+static struct timeval timeout = /* 100 ms */ { 0, 10L };
+fd_set fdread, fdwrite, fdexcep;
+int maxfd = -1;
+
res = (int)curl_multi_perform(m, running);
if (tutil_tvdiff(tutil_tvnow(), mp_start)
MULTI_PERFORM_HANG_TIMEOUT) {
@@ -148,6 +152,22 @@ int test(char *URL)
fprintf(stderr, nothing left running.\n);
break;
}
+
+FD_ZERO(fdread);
+FD_ZERO(fdwrite);
+FD_ZERO(fdexcep);
+curl_multi_fdset(m, fdread, fdwrite, fdexcep, maxfd);
+
+/* In a real-world program you OF COURSE check the return code of the
+ function calls. On success, the value of maxfd is guaranteed to be
+ greater or equal than -1. We call select(maxfd + 1, ...), specially in
+ case of (maxfd == -1), we call select(0, ...), which is basically equal
+ to sleep. */
+
+if (select(maxfd + 1, fdread, fdwrite, fdexcep, timeout) == -1) {
+ res = ~CURLM_OK;
+ break;
+}
}
if (mp_timedout) {
diff --git a/tests/libtest/lib573.c b/tests/libtest/lib573.c
index 4661858..79b22dd 100644
--- a/tests/libtest/lib573.c
+++ b/tests/libtest/lib573.c
@@ -76,6 +76,10 @@ int test(char *URL)
mp_start = tutil_tvnow();
while (running) {
+static struct timeval timeout = /* 100 ms */ { 0, 10L };
+fd_set fdread, fdwrite, fdexcep;
+int maxfd = -1;
+
res = (int)curl_multi_perform(m, running);
if (tutil_tvdiff(tutil_tvnow(), mp_start)
MULTI_PERFORM_HANG_TIMEOUT) {
@@ -86,6 +90,22 @@ int test(char *URL)
fprintf(stderr, nothing left running.\n);
break;
}
+
+FD_ZERO(fdread);
+FD_ZERO(fdwrite);
+FD_ZERO(fdexcep);
+curl_multi_fdset(m, fdread, fdwrite, fdexcep, maxfd);
+
+/* In a real-world program you OF COURSE check the return code of the
+ function calls. On success, the value of maxfd is guaranteed to be
+ greater or equal than -1. We call select(maxfd + 1, ...), specially in
+ case of (maxfd == -1), we call select(0, ...), which is basically equal
+ to sleep. */
+
+if (select(maxfd + 1, fdread, fdwrite, fdexcep, timeout) == -1) {
+ res = ~CURLM_OK;
+ break;
+}
}
if (mp_timedout) {
--
1.7.4.4
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: busy loops in tests 502, 555, and 573
On Fri, 26 Aug 2011, Kamil Dudka wrote: I spotted that tests 502, 555, and 573 do not call select() when looping around curl_multi_perform(). Is that intentionally? No, I can't remember that being intentional. I blame plain laziness! =) -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: sftp download issue (Daniel Stenberg)
On Thu, 25 Aug 2011, Sumukh Anantha Manohar wrote: Libraries: libssh2-1.2.9 This turned out to be a flaw in libssh2 and I just now pushed a fix there: http://git.libssh2.org/?p=libssh2.git;a=commitdiff;h=900c90ccbe9;js=1 I haven't yet actually tested this with (lib)curl, but I could easily repeat this problem with only libssh2 before the fix. I'm interested in feedback. -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: sftp download issue (Daniel Stenberg)
Daniel Stenberg skrev 2011-08-26 12:01: I haven't yet actually tested this with (lib)curl, but I could easily repeat this problem with only libssh2 before the fix. I'm interested in feedback. Just gave it a test run with the fix applied to libssh2 1.2.8 (which I had lying around, so quick to test out) together with curl and my previous issues are all resolved, my entire test batch of file went through without any issue! This with win32 build on 64 bit Windows 7. Best regards Patrik Thunström / patrik.thunst...@bassetglobal.com --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [PATCH] SMTP Modifications
2011/8/26 Steve Holme wrote: 0001-Added-support-for-NTLM-authentication-to-SMTP.patch I have enclosed a patch adding NTLM support to SMTP. Please note that halfway through this patch I realised that Curl_ntlm_create_type1_message() and Curl_ntlm_create_type3_message didn't support the outlen / size parameter (as I had written a couple of weeks ago). As such, this patch includes the addition of this parameter to these functions, as well as the actual addition of NTLM to SMTP. I hope this is acceptable, rather than splitting the work into two patches, so for speed and as it's almost midnight and I need to get some sleep I have attached one patch ;-) If case the length of the string returned by Curl_ntlm_create_type1_message() and Curl_ntlm_create_type3_message() at least was used somewhere I could find a reason to let these functions return its value using outlen. Given that it is not used I find no need right now to change the interface of these two functions. Steve, please, look at your patch the outlen is given no real use. Actually smtp_auth_ntlm() in this patch should not have the outlen parameter. In smpt.h you introduce new SMTP_AUTHNTLM and SMTP_AUTHNTLMTYPE2 in smtpstate enum. And in smtp.c you introduce new functions smtp_state_auth_ntlm_resp() and smtp_state_auth_ntlm_type2_resp(). When you are creating them it is esay to remember what they do and what the states mean. But if you read the code that uses those functions two or three months later, or anyone else right now, you could start wondering with the smtpstate enum if both NTLM and NTLM 2 are used and something similar happens with those function names. It would be more clear if 'msg-typeX' or something were used in those names. Aha!, but what actually happens is that you are introducing these to somehow allow disabling the 'initial-response' sending in the AUTH command for the NTLM authentication. In any case bad choice of names. You also place NTLM authentication as the preferred method above any aother one. I wonder if this should be the preferred method and if STARTTLS influence should be considered in this placement. For all of the above I have to reject this patch. In case mentioned problems above didn't exist, given that we are in feature freeze period and that it introduces functional changes we neither can accept it. Changes which represented no functional change, or that represented true fixes even for marginal cases, have been done for nearly a month now in preparation for the new functionalities. So lets do things right when these can finally be introduced. Is there something that I might have missed that still needs 'fixing' or preparation but that truly introduces no functional change, and that we could evaluate if it could be accepted in feature freeze period? -- -=[Yang]=- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
RE: [PATCH] SMTP Modifications
Hi Yang, Actually smtp_auth_ntlm() in this patch should not have the outlen parameter. The outlen parameter is used in smtp_authenticate() when calculating if the buffer is within length. This is how all the smtp_auth* functions work. It would be more clear if 'msg-typeX' or something were used in those names. No problems - I can change the state and function names if you would like me to. I guess you could say, I am still trying to find the right balance between meaningful names and not too long names for things within Curl. Aha!, but what actually happens is that you are introducing these to somehow allow disabling the 'initial-response' sending in the AUTH command for the NTLM authentication. Not at all. The 'intial-response' disabling is not present in this patch and as such the contents returned by smtp_auth_ntlm() will be the 'initial-response' in smtp_authenticate(). To a certain degree, you could argue that smtp_auth_ntlm_resp() is not needed (at present), however, AUTH PLAIN and AUTH LOGIN have a corresponding response function for when the 'initial-response' is disabled. In reality they never get called, as the variable state1 only gets used when initresp is empty or the length of the response is longer than 504 characters. For the sake of clarity and consistency, and the odd occasion that the output from smtp_auth_login_user(), smtp_auth_login_plain_data() and smtp_auth_login_ntlm() is between 504 and 514 characters long, I have provided the same - I am happy to remove smtp_auth_ntlm_resp() if you would like me to, but I would also recommend removing smtp_state_authplain_resp() and smtp_state_authlogin_resp() as well ;-) You also place NTLM authentication as the preferred method above any aother one. I wonder if this should be the preferred method and if STARTTLS influence should be considered in this placement. This was based on my own testing with Exchange Server but I am happy to move the placement of AUTH NTLM to below AUTH CRAM-MD5, if you would like me to, as I don't know which of these mechanism's is more secure. However, NTLM is more secure than both AUTH LOGIN AND AUTH PLAIN regardless of whether TLS is on or off. In case mentioned problems above didn't exist, given that we are in feature freeze period and that it introduces functional changes we neither can accept it. How would you like me to proceed with this, as this is functionality that was present in my original two patches from July and is subsequently on Daniel's TODO list for v7.22.0 as items 303 and 304? Kind Regards Steve --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Re: Re: Re: [PATCH] allows curl to be able to send the custom headers with empty value.
On Thu, 25 Aug 2011, warp.kaw...@gmail.com wrote: If you would use this spec then its patch is below. How about this? Your patch seems to have lost all whitespaces so it looks completely destroyed. + ptr = strchr(headers-data, ';'); + /* send non-value custom header if terminated by semicolon */ This looks for a semicolon _anywhere_ in a custom header, so a common thing like Content-Type: text/html; charset=utf8; would match. The check needs to be stricter. Possibly tok=strtok_r(header, ;:, tok_buf); ... and check if 'tok' is non-NULL and points to a semicolon. -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
