Re: Errors/crashes with FTP using multi interface?
On 29 Mar 2013, at 20:29, Daniel Stenberg dan...@haxx.se wrote: Try the attached patch, also pushed to git. Makes the crash go away for me... Hi Daniel, Sorry for the slow response - I was working on a different project last week so didn't get a chance to test your patch properly. It seems to have fixed the test case for me (unsurprisingly), and also to have fixed all of our original issues. Many thanks for your help, - Sam - sam deane / @samdeane | elegantchaos.com / @elegantchaoscom | mac and ios software development --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Errors/crashes with FTP using multi interface?
On 28 Mar 2013, at 22:15, Daniel Stenberg dan...@haxx.se wrote: 1. You didn't eliminate gcd completely. I had to remove a bunch of more uses. I didn't claim to have eliminated GCD. I said I'd eliminated GCD dispatch sources - which had been one of the things we were wondering about, because of the way they work. 2. You extracted a URL with CURLINFO_EFFECTIVE_URL and then you freed the handle before you used the data so you deferred already freed memory. This is true. 3. You freed the list you extracted with CURLINFO_PRIVATE _before_ you cleaned up the handle and thus caused another deferring of freed memory. This is also true. See attached source that has these flaws fixed. Works fine for me. I'm afraid that I can't accept your attached source, as it's not in the correct patch format ;) Only kidding. However, your attached source had the following lines in it: #if 0 curl_easy_setopt(handle, CURLOPT_POSTQUOTE, list); #endif Turning off the post quote stuff does indeed fix the crash. Turning it back on again, however, causes it to crash, with your (non-gcd) version. The backtrace is pretty consistent: * thread #1: tid = 0x2503, 0x00010006458f libcares.dylib`ares_destroy(channel=0x000100812a00) + 50 at ares_destroy.c:55, stop reason = EXC_BAD_ACCESS (code=13, address=0x0) frame #0: 0x00010006458f libcares.dylib`ares_destroy(channel=0x000100812a00) + 50 at ares_destroy.c:55 frame #1: 0x000100014fa2 libcurl.dylib`Curl_close(data=0x000100850a00) + 526 at url.c:440 frame #2: 0x0001156d crashtest`curl_perform_wait + 541 at multi-nogcd-crashtest.c:82 frame #3: 0x000119e8 crashtest`main(argc=0, argv=0x7fff5fbff328) + 184 at multi-nogcd-crashtest.c:167 frame #4: 0x7fff902697e1 libdyld.dylib`start + 1 It seems to happen just after the third connection has been added. I've attached my modified source. multi-nogcd-crashtest.c Description: Binary data --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Errors/crashes with FTP using multi interface?
On Fri, 29 Mar 2013, Sam Deane wrote: It seems to happen just after the third connection has been added. Try the attached patch, also pushed to git. Makes the crash go away for me... -- / daniel.haxx.seFrom ca62ac69bbda381b3ba3a7b8bca63e82e84743ab Mon Sep 17 00:00:00 2001 From: Daniel Stenberg dan...@haxx.se Date: Fri, 29 Mar 2013 21:19:45 +0100 Subject: [PATCH] ftp_sendquote: use PPSENDF, not FTPSENDF The last remaining code piece that still used FTPSENDF now uses PPSENDF. In the problematic case, a PREQUOTE series was done on a re-used connection when Curl_pp_init() hadn't been called so it had messed up pointers. The init call is done properly from Curl_pp_sendf() so this change fixes this particular crash. Bug: http://curl.haxx.se/mail/lib-2013-03/0319.html Reported by: Sam Deane --- lib/ftp.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/lib/ftp.c b/lib/ftp.c index d9b8547..dec4800 100644 --- a/lib/ftp.c +++ b/lib/ftp.c @@ -162,8 +162,6 @@ static CURLcode ftp_dophase_done(struct connectdata *conn, bool connected); /* easy-to-use macro: */ -#define FTPSENDF(x,y,z)if((result = Curl_ftpsendf(x,y,z)) != CURLE_OK) \ - return result #define PPSENDF(x,y,z) if((result = Curl_pp_sendf(x,y,z)) != CURLE_OK) \ return result @@ -3523,7 +3521,7 @@ CURLcode ftp_sendquote(struct connectdata *conn, struct curl_slist *quote) acceptfail = TRUE; } - FTPSENDF(conn, %s, cmd); + PPSENDF(conn-proto.ftpc.pp, %s, cmd); pp-response = Curl_tvnow(); /* timeout relative now */ -- 1.7.10.4 --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Errors/crashes with FTP using multi interface?
On 13 Feb 2013, at 22:51, Daniel Stenberg dan...@haxx.se wrote: You don't need to convert anything to our standard test format, but if you want us to really be able to help you debug this then you must help us repeat the problem. The easiest way to do that is for you to write a new and stand-alone libcurl-using app (I'd prefer it being in plain standard C) that repeats your application's behavior and then hopefully(!) also repeats the bug. For what it's worth, I now have a test case which appears to repeat my crash, or something very similar. It's a plain C app, but it requires GCD (libdispatch). multi-gcd-crashtest.c Description: Binary data For me, it crashes reliably with a single URL input of: ftp://ftptest:ftptest@10.0.1.32/crashtest/ The server 10.0.1.32 is running, and has a directory called crashtest which contains some subdirectories. The test performs some post-quote commands on an ftp (or sftp) url. When the easy handle completes, the test resubmits another request for the same command, so in effect it's just doing the same thing again and again. This is an attempt to reproduce the situation where I see the crash in my real code - which is just after one easy handle completing and another being adding to a multi, when both are performing post-quote commands on the same server. The test sets quite a lot of options, and installs lots of callback functions. Again, this was an attempt to reproduce the setup in my real code. It is possible that the crash will reproduce without a lot of those settings, but I've not tested that yet. The crash happens in a number of different places, but here's an example trace: * thread #2: tid = 0x3103, 0x00010003bf2b libcurl.dylib`Curl_pp_readresp(sockfd=4, pp=0x000100806508, code=0x000100780ad4, size=0x000100780b20) + 794 at pingpong.c:379, stop reason = EXC_BAD_ACCESS (code=1, address=0x10280) frame #0: 0x00010003bf2b libcurl.dylib`Curl_pp_readresp(sockfd=4, pp=0x000100806508, code=0x000100780ad4, size=0x000100780b20) + 794 at pingpong.c:379 frame #1: 0x000100011e43 libcurl.dylib`ftp_readresp(, ftpcode=0x000100780b8c) + 29 at ftp.c:627 frame #2: 0x000100011dab libcurl.dylib`Curl_GetFTPResponse(nreadp=0x000100780b90, conn=0x000100806000) + 227 at ftp.c:759 frame #3: 0x0001000115ec libcurl.dylib`ftp_done [inlined] ftp_sendquote(, conn=0x000100806000) + 86 at ftp.c:3530 frame #4: 0x000100011596 libcurl.dylib`ftp_done(conn=0x000100806000, status=CURLE_OK, premature=false) + 1258 at ftp.c:3485 frame #5: 0x00010001c8ed libcurl.dylib`Curl_done(connp=0x000101a00038) + 271 at url.c:5425 frame #6: 0x000100029eae libcurl.dylib`multi_runsingle(multi=0x00010060, now=(null), easy=0x000101a00020) + 1580 at multi.c:1577 frame #7: 0x00010002b0ee libcurl.dylib`multi_socket(multi=0x00010060, checkall=true, s=-1, running_handles=0x000100780d94) + 420 at multi.c:2194 frame #8: 0x00010002b180 libcurl.dylib`curl_multi_socket_action(multi_handle=0x00010060) + 27 at multi.c:2297 frame #9: 0x0001126a crashtest`curl_perform_action(socket=-1, actions=0) + 42 at multi-gcd-crashtest.c:101 frame #10: 0x0001209d crashtest`__create_timeout_block_invoke(.block_descriptor=0x00013210) + 29 at multi-gcd-crashtest.c:167 frame #11: 0x7fff995710b6 libdispatch.dylib`_dispatch_client_callout + 8 frame #12: 0x7fff9957329b libdispatch.dylib`_dispatch_source_invoke + 691 frame #13: 0x7fff99572305 libdispatch.dylib`_dispatch_queue_invoke + 72 frame #14: 0x7fff99572448 libdispatch.dylib`_dispatch_queue_drain + 180 frame #15: 0x7fff995722f1 libdispatch.dylib`_dispatch_queue_invoke + 52 frame #16: 0x7fff995721c3 libdispatch.dylib`_dispatch_worker_thread2 + 249 frame #17: 0x7fff99731d0b libsystem_c.dylib`_pthread_wqthread + 404 frame #18: 0x7fff9971c1d1 libsystem_c.dylib`start_wqthread + 13 Code versions I'm using are: libcurl/7.30.0-DEV SecureTransport zlib/1.2.5 c-ares/1.9.0-DEV libssh2/1.4.3_DEV I've also enclosed a much cleaner and simpler version of the test, which doesn't crash, but simply illustrates how to use libcurl with gcd and dispatch sources. multi-gcd.c Description: Binary data --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Errors/crashes with FTP using multi interface?
A follow-up to the message I just sent. I've managed to strip out quite a bit of extraneous stuff from the example I sent earlier. This one is more compact, and still crashes. multi-gcd-crashtest.c Description: Binary data Critical ingredients seem to be: Using FTP. Setting CURLOPT_POSTQUOTE. Setting CURLOPT_CONNECTTIMEOUT Setting CURLOPT_NOBODY--- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Errors/crashes with FTP using multi interface?
On Thu, 28 Mar 2013, Sam Deane wrote:
I've eliminated GCD dispatch sources as a culprit I think, by writing an
alternative version of the test which uses
curl_multi_wait/curl_multi_perform, instead of curl_multi_socket_action plus
callbacks.
This one also exhibits the same crash:
1. You didn't eliminate gcd completely. I had to remove a bunch of more uses.
2. You extracted a URL with CURLINFO_EFFECTIVE_URL and then you freed the
handle before you used the data so you deferred already freed memory.
3. You freed the list you extracted with CURLINFO_PRIVATE _before_ you cleaned
up the handle and thus caused another deferring of freed memory.
See attached source that has these flaws fixed. Works fine for me.
--
/ daniel.haxx.se/***
* _ _ _
* Project ___| | | | _ \| |
* / __| | | | |_) | |
*| (__| |_| | _ | |___
* \___|\___/|_| \_\_|
*
* Copyright (C) 1998 - 2013, Daniel Stenberg, dan...@haxx.se, et al.
*
* This software is licensed as described in the file COPYING, which
* you should have received as part of this distribution. The terms
* are also available at http://curl.haxx.se/docs/copyright.html.
*
* You may opt to use, copy, modify, merge, publish, distribute and/or sell
* copies of the Software, and permit persons to whom the Software is
* furnished to do so, under the terms of the COPYING file.
*
* This software is distributed on an AS IS basis, WITHOUT WARRANTY OF ANY
* KIND, either express or implied.
*
***/
/* Example application code using the multi socket interface to download
multiple files at once, but instead of using curl_multi_perform and
curl_multi_wait, which uses select(), we use gcd.
*/
#include stdio.h
#include stdlib.h
#include curl/curl.h
#include string.h
#define log_message(...) fprintf(stderr, __VA_ARGS__)
#define log_error(...) fprintf(stderr, ERROR: __VA_ARGS__)
void add_download(const char *url);
int remaining = 0;
int repeats = 20;
CURLM *curl_handle;
void curl_perform_wait()
{
long timeout_ms = -1;
CURLMcode result = curl_multi_timeout(curl_handle, timeout_ms);
if (result != CURLM_OK) log_error(curl_multi_timeout error %d, result);
if (timeout_ms 1) timeout_ms = 1;
int numfds = 0;
result = curl_multi_wait(curl_handle, NULL, 0, (int)timeout_ms, numfds);
if (result != CURLM_OK) log_error(curl_multi_wait error %d, result);
int numrunning = 0;
result = curl_multi_perform(curl_handle, numrunning);
if (result != CURLM_OK) log_error(curl_multi_perform error %d, result);
int pending = 0;
CURLMsg *message;
while ((message = curl_multi_info_read(curl_handle, pending))) {
switch (message-msg) {
case CURLMSG_DONE:
{
const char* done_url;
CURL* easy = message-easy_handle;
curl_easy_getinfo(easy, CURLINFO_EFFECTIVE_URL, done_url);
CURLcode code = message-data.result;
printf(%s DONE\ncode:%d - %s\n, done_url, code,
curl_easy_strerror(code));
struct curl_slist* list;
curl_easy_getinfo(easy, CURLINFO_PRIVATE, list);
--remaining;
if (--repeats)
{
add_download(done_url);
}
curl_multi_remove_handle(curl_handle, easy);
curl_easy_cleanup(easy);
curl_slist_free_all(list);
break;
}
default:
log_error(CURLMSG default\n);
abort();
}
}
if (remaining == 0)
{
curl_multi_cleanup(curl_handle);
exit(0);
}
}
int debug_func(CURL *curl, curl_infotype infoType, char *info, size_t infoLength, void *userp)
{
char* string = strndup(info, infoLength);
fprintf(stderr, debug %d: %s, infoType, string);
free(string);
return 0;
}
void add_download(const char *url)
{
CURL *handle = curl_easy_init();
curl_easy_setopt(handle, CURLOPT_URL, url);
curl_easy_setopt(handle, CURLOPT_DEBUGFUNCTION, debug_func);
curl_easy_setopt(handle, CURLOPT_VERBOSE, 1);
curl_easy_setopt(handle, CURLOPT_URL, url);
char randomname[CURL_ERROR_SIZE];
char makecmd[CURL_ERROR_SIZE];
char chmodcmd[CURL_ERROR_SIZE];
char delcmd[CURL_ERROR_SIZE];
sprintf(randomname, test-%d, rand());
sprintf(makecmd, *MKD %s, randomname);
sprintf(chmodcmd, SITE CHMOD 0744 %s, randomname);
sprintf(delcmd, DELE %s, randomname);
struct curl_slist* list =
Re: Errors/crashes with FTP using multi interface?
On 13 Feb 2013, at 22:51, Daniel Stenberg dan...@haxx.se wrote: You don't need to convert anything to our standard test format, but if you want us to really be able to help you debug this then you must help us repeat the problem. The easiest way to do that is for you to write a new and stand-alone libcurl-using app (I'd prefer it being in plain standard C) that repeats your application's behavior and then hopefully(!) also repeats the bug. Thanks Daniel. I understand that you need a repeatable bug in order to help. I do have that, in the form of the unit test that I mentioned. I also understand why you'd like a plain C version, but that will take time, and I'll have to ask if my clients are willing to fund it :) I think I could strip away the Objective-C layer, but I don't think it would make sense to strip away the use of GCD, as it will change the code so fundamentally that it won't really be the same situation at all at that point. Much as I'd love someone to step in an help debug it though, I do realise that this is an open source project. My main purpose in mailing the list was simply to put the problem out there, on the off-chance that someone recognises the symptoms and knows what I'm doing wrong (or confirms that it's probably a libcurl bug). --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Errors/crashes with FTP using multi interface?
On 7 Feb 2013, at 23:07, Nick Zitzmann n...@chronosnet.com wrote: If you get any more stalls with the latest code, could you share a stack trace sample when the stall occurs, or (even better) a sample project that reproduces the problem? I've only noticed one stall recently that wasn't caused by the connection to the server, and it was due to an IPv6-related bug that was fixed last week. A bit more followup on this one, fwiw: Looking at the debug output from curl, there are some differences between the upload that works, and the one that gets stuck. Here's the working one: 14:30:06.191 DEBUG - Connected to 10.0.1.32 (10.0.1.32) port 21 (#0) 14:30:06.191 DEBUG - FTP 0x102019d18 (line 3246) state change from STOP to WAIT220 14:30:06.192 DEBUG - STATE: WAITCONNECT = PROTOCONNECT handle 0x100330150; line 1145 (connection #0) 14:30:06.215 HEADER_IN - 220 10.0.1.32 FTP server (tnftpd 20100324+GSSAPI) ready. 14:30:06.217 HEADER_OUT - USER ftptest 14:30:06.218 DEBUG - FTP 0x102019d18 (line 845) state change from WAIT220 to USER 14:30:06.234 HEADER_IN - 331 User ftptest accepted, provide password. 14:30:06.235 HEADER_OUT - PASS ftptest 14:30:06.236 DEBUG - FTP 0x102019d18 (line 2630) state change from USER to PASS 14:30:06.259 HEADER_IN - 230 User ftptest logged in. 14:30:06.260 HEADER_OUT - PWD 14:30:06.260 DEBUG - FTP 0x102019d18 (line 857) state change from PASS to PWD 14:30:06.289 HEADER_IN - 257 /Users/ftptest is the current directory. 14:30:06.290 DEBUG - Entry path is '/Users/ftptest' 14:30:06.291 DEBUG - FTP 0x102019d18 (line 2938) state change from PWD to STOP 14:30:06.292 DEBUG - protocol connect phase DONE 14:30:06.292 DEBUG - STATE: PROTOCONNECT = DO handle 0x100330150; line 1164 (connection #0) 14:30:06.293 DEBUG - DO phase starts 14:30:06.293 HEADER_OUT - CWD CURLHandleTests 14:30:06.294 DEBUG - FTP 0x102019d18 (line 942) state change from STOP to CWD 14:30:06.312 HEADER_IN - 250 CWD command successful. 14:30:06.318 HEADER_OUT - PASV 14:30:06.318 DEBUG - FTP 0x102019d18 (line 1365) state change from CWD to PASV 14:30:06.319 DEBUG - Connect data stream passively 14:30:06.319 DEBUG - STATE: DO = DOING handle 0x100330150; line 1223 (connection #0) 14:30:06.358 HEADER_IN - 227 Entering Passive Mode (10,0,1,32,218,29) 14:30:06.360 DEBUG - Trying 10.0.1.32... 14:30:06.360 DEBUG - Connecting to 10.0.1.32 (10.0.1.32) port 55837 14:30:06.361 DEBUG - FTP 0x102019d18 (line 2083) state change from PASV to STOP 14:30:06.361 DEBUG - DO phase is complete2 14:30:06.425 DEBUG - STATE: DOING = DO_MORE handle 0x100330150; line 1310 14:30:06.430 HEADER_OUT - TYPE I 14:30:06.431 DEBUG - FTP 0x102019d18 (line 3579) state change from STOP to STOR_TYPE 14:30:06.432 HEADER_IN - 200 Type set to I. 14:32:16.014 HEADER_OUT - STOR Upload.txt 14:32:16.015 DEBUG - FTP 0x102019d18 (line 1696) state change from STOR_TYPE to STOR 14:32:16.018 HEADER_IN - 150 Opening BINARY mode data connection for 'Upload.txt'. 14:32:16.019 DEBUG - FTP 0x102019d18 (line 533) state change from STOR to STOP 14:32:16.022 DEBUG - STATE: DO_MORE = DO_DONE handle 0x100330150; line 1332 14:32:16.027 DEBUG - STATE: DO_DONE = WAITPERFORM handle 0x100330150; line 14:32:16.057 DEBUG - STATE: WAITPERFORM = PERFORM handle 0x100330150; line 14:32:16.064 DATA_OUT - *|*|* Some test content. Blah blah... *|*|* 14:32:16.065 DEBUG - We are completely uploaded and fine 14:32:16.065 DEBUG - STATE: PERFORM = DONE handle 0x100330150; line 1533 14:32:16.066 DEBUG - Remembering we are in dir CURLHandleTests/ 14:32:16.068 HEADER_IN - 226 Transfer complete. Here's the one that's getting stuck: 14:32:16.143 DEBUG - Found bundle for host 10.0.1.32: 0x1003301b0 14:32:16.144 DEBUG - Re-using existing connection! (#0) with host 10.0.1.32 14:32:16.145 DEBUG - Connected to 10.0.1.32 (10.0.1.32) port 21 (#0) 14:32:16.146 DEBUG - 0x1020e2000 is at send pipe head! 14:32:16.147 DEBUG - STATE: CONNECT = DO handle 0x1001c8020; line 1025 (connection #0) 14:32:16.148 DEBUG - Request has same path as previous transfer 14:32:16.149 DEBUG - DO phase starts 14:32:16.150 HEADER_OUT - PASV 14:32:16.151 DEBUG - FTP 0x102019d18 (line 1365) state change from STOP to PASV 14:32:16.152 DEBUG - Connect data stream passively 14:32:16.153 HEADER_IN - 227 Entering Passive Mode (10,0,1,32,218,41) 14:32:16.155 DEBUG - Trying 10.0.1.32... 14:32:16.156 DEBUG - Connecting to 10.0.1.32 (10.0.1.32) port 55849 14:32:16.157 DEBUG - FTP 0x102019d18 (line 2083) state change from PASV to STOP 14:32:16.158 DEBUG - DO phase is complete1 14:32:16.159 DEBUG - FTP 0x102019d18 (line 3574) state change from STOP to STOR_TYPE 14:32:16.159 HEADER_OUT - STOR Upload.txt 14:32:16.161 DEBUG - FTP 0x102019d18 (line 1696) state change from STOR_TYPE to STOR 14:32:16.162 HEADER_IN - 150 Opening BINARY mode data connection for 'Upload.txt'. 14:32:16.164 DEBUG - FTP 0x102019d18 (line 533) state change from STOR to STOP 14:32:16.165 DEBUG - STATE: DO = DO_MORE handle 0x1001c8020; line 1231
Re: Errors/crashes with FTP using multi interface?
On 7 Feb 2013, at 23:07, Nick Zitzmann n...@chronosnet.com wrote: f you get any more stalls with the latest code, could you share a stack trace sample when the stall occurs, or (even better) a sample project that reproduces the problem? I've only noticed one stall recently that wasn't caused by the connection to the server, and it was due to an IPv6-related bug that was fixed last week. I'm still getting problems with the latest code (commit fe2b2a3b9dbe18883cf7c9789cd958915978dc3a). The project showing the problem is open source, Xcode based, with a SenTest style unit test illustrating the problem. I'm happy to share it if you want (let me know). I'm not sure how feasible it would be to massage this into your standard test format since there's a fair bit of Objective-c wrapping around the libcurl code (which is the whole point). The two problems I'm seeing are… 1) I'm getting the crash that I described previously, where an incorrect nmemb value is coming through to the callback from Curl_pp_readresp: #4 0x0001007c9d0e in -[CURLHandle curlReceiveDataFrom:size:number:isHeader:] at /Volumes/titan/Users/sam/Work/clients/karelia/ConnectionKit/CurlHandle/CURLHandleSource/CURLHandle.m:677 #5 0x0001007c91c0 in curlHeaderFunction at /Volumes/titan/Users/sam/Work/clients/karelia/ConnectionKit/CurlHandle/CURLHandleSource/CURLHandle.m:1074 #6 0x000102c0b228 in Curl_client_write at /Volumes/titan/Users/sam/Work/clients/karelia/ConnectionKit/CurlHandle/CURLHandleSource/build/curl-x86_64/lib/sendf.c:476 #7 0x000102c35d9f in Curl_pp_readresp at /Volumes/titan/Users/sam/Work/clients/karelia/ConnectionKit/CurlHandle/CURLHandleSource/build/curl-x86_64/lib/pingpong.c:393 #8 0x000102c0caee in ftp_readresp at /Volumes/titan/Users/sam/Work/clients/karelia/ConnectionKit/CurlHandle/CURLHandleSource/build/curl-x86_64/lib/ftp.c:627 #9 0x000102c0ca56 in Curl_GetFTPResponse at /Volumes/titan/Users/sam/Work/clients/karelia/ConnectionKit/CurlHandle/CURLHandleSource/build/curl-x86_64/lib/ftp.c:759 #10 0x000102c0c2b0 in ftp_sendquote [inlined] at /Volumes/titan/Users/sam/Work/clients/karelia/ConnectionKit/CurlHandle/CURLHandleSource/build/curl-x86_64/lib/ftp.c:3530 #11 0x000102c0c25a in ftp_done at /Volumes/titan/Users/sam/Work/clients/karelia/ConnectionKit/CurlHandle/CURLHandleSource/build/curl-x86_64/lib/ftp.c:3485 #12 0x000102c1731a in Curl_done at /Volumes/titan/Users/sam/Work/clients/karelia/ConnectionKit/CurlHandle/CURLHandleSource/build/curl-x86_64/lib/url.c:5234 #13 0x000102c24a39 in multi_runsingle at /Volumes/titan/Users/sam/Work/clients/karelia/ConnectionKit/CurlHandle/CURLHandleSource/build/curl-x86_64/lib/multi.c:1563 #14 0x000102c25a00 in multi_socket at /Volumes/titan/Users/sam/Work/clients/karelia/ConnectionKit/CurlHandle/CURLHandleSource/build/curl-x86_64/lib/multi.c:2178 #15 0x000102c25a92 in curl_multi_socket_action at /Volumes/titan/Users/sam/Work/clients/karelia/ConnectionKit/CurlHandle/CURLHandleSource/build/curl-x86_64/lib/multi.c:2258 #16 0x0001007cd70f in -[CURLMulti multiProcessAction:forSocket:] at /Volumes/titan/Users/sam/Work/clients/karelia/ConnectionKit/CurlHandle/CURLHandleSource/CURLMulti.m:284 #17 0x0001007ce64b in __24-[CURLMulti createTimer]_block_invoke at /Volumes/titan/Users/sam/Work/clients/karelia/ConnectionKit/CurlHandle/CURLHandleSource/CURLMulti.m:436 2) The stall that I mentioned is also still happening. It's not a deadlock situation as such, so there's no meaningful stack trace I can give you, but what seems to happen is that the timeout function that I set up to service the multi keeps ticking, but nothing actually happens to the easy handle. It's not clear to me why at this point. The test performs a series of uploads of the same file, to the same server, one after another. For each upload the test sets it going, then loops on the current run loop until a flag is set. It relies on success/failure information coming through via the callbacks to set this flag. The first upload succeeds, but the second one doesn't seem to complete - the flag isn't set, and so we end up stuck in the code that's pumping the run loop. (apologies if some of this OS X terminology doesn't make any sense, but you can probably guess roughly what I'm referring to). Here's some log, starting at the point where the first upload has succeeded. CURLHandle and CURLMulti are my objective C wrappers for easy and multi handles. One thing that's a bit weird is that at the point that we get stuck, curl_multi_socket_action seems to return a running count of 1, then of 0, then of 1, and so on... 2013-02-13 15:14:08.362 otest[32724:1803] CURLHandle 0x1001400b0 (easy 0x10087ec00): DEBUG - We are completely uploaded and fine 2013-02-13 15:14:08.363 otest[32724:1803] CURLHandle 0x1001400b0 (easy 0x10087ec00): DEBUG - STATE: PERFORM = DONE handle
Re: Errors/crashes with FTP using multi interface?
One thing that's a bit weird is that at the point that we get stuck, curl_multi_socket_action seems to return a running count of 1, then of 0, then of 1, and so on... I've realised that this was a red herring - there are two multis alive at that point in the test, and the timer for each is running in turn. It is correct that one of them should have no running handles, and one should have one. The rest of what I said still stands though. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Errors/crashes with FTP using multi interface?
Hi Nick, Apologies if this reply breaks the thread - I forgot that I had email delivery turned off for this list, so I've just seen your reply, and don't have an actual mail to reply to. I believe that I have the threading set up correctly. You believe you do. Can you confirm that? Our app doesn't use multi handles, but it uses multiple easy handles at once, each protected by locks, with no problems. Well, it's hard to prove a negative, but I don't believe I've messed up the protection. All access to the multi is protected by a serial CGD queue, meaning that although curl_multi routines may be called from different threads, we're guaranteed that only one thread will ever access it at one time. I have a number of debugging checks and assertions which seem to confirm that this is working correctly. Also, is this happening in the code in the trunk, or in a released version, or in Apple's shared libcurl library? If it's anything but the trunk, can you build the trunk and test that? There has been a lot of changes in the trunk since the last point release of libcurl. We built the library ourselves, and it was in the latest release version (although I think a newer one has just been released). We did try the trunk, but ran into some other problems with that - instead of getting server did not report OK errors, we were getting stalls instead where an upload/download simply failed to finish. This prevented us from confirming whether the crash was still there. I'm not working on the code this week (it's a contracting job), but I'll look at it again next week, with the latest release version and/or the trunk version. Cheers, - Sam - sam deane / @samdeane | elegantchaos.com / @elegantchaoscom | mac and ios software development --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Errors/crashes with FTP using multi interface?
On Feb 7, 2013, at 7:17 AM, Sam Deane s...@elegantchaos.com wrote: We did try the trunk, but ran into some other problems with that - instead of getting server did not report OK errors, we were getting stalls instead where an upload/download simply failed to finish. This prevented us from confirming whether the crash was still there. If you get any more stalls with the latest code, could you share a stack trace sample when the stall occurs, or (even better) a sample project that reproduces the problem? I've only noticed one stall recently that wasn't caused by the connection to the server, and it was due to an IPv6-related bug that was fixed last week. Nick Zitzmann http://www.chronosnet.com/ --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Errors/crashes with FTP using multi interface?
On Feb 4, 2013, at 5:28 AM, Sam Deane s...@elegantchaos.com wrote: It may be a coincidence, but at some level both problems appear to be caused by the curl internals getting confused about which response it's supposed to be processing. This leads me to suspect that the underlying issue may be the same. Does anyone have any ideas? I believe that I have the threading set up correctly. You believe you do. Can you confirm that? Our app doesn't use multi handles, but it uses multiple easy handles at once, each protected by locks, with no problems. Also, is this happening in the code in the trunk, or in a released version, or in Apple's shared libcurl library? If it's anything but the trunk, can you build the trunk and test that? There has been a lot of changes in the trunk since the last point release of libcurl. Nick Zitzmann http://www.chronosnet.com/ --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
