I have debugged the issue and made a quick fix. I'm not sure if this fix is correct and it does not make any harm for other protocols etc, because my familiarity with cURL source code is pretty low. Anyway I tested my changes using make test with this result:
TESTDONE: 548 tests out of 548 reported OK: 100%
TESTDONE: 631 tests were considered during 215 seconds.

...but make test-torture gave information about segmentation faults in some of the tests.

Here is my fix. In file multi.c, at the end of function multi_runsingle(...) I made a change marked with comment:

      /* if there's still a connection to use, call the progress function */
      else if(easy->easy_conn && Curl_pgrsUpdate(easy->easy_conn)) {
        easy->result = CURLE_ABORTED_BY_CALLBACK;
        multistate(easy, CURLM_STATE_COMPLETED); // line added by me
      }

This change makes the transfer to stop immediately after returning from callback, but I don't know if it makes proper cleanup of connection.

Unfortunately there is one more bug that is reproduced in 100% in my test case (regardless its a libcurl code with my fix or without it). When I do curl_multi_remove_handle, program enters infinite loop and eats 75% of CPU.

Now I plan to write a test case for cURL's test suite. I didn't have chance to look more deeply into these tests, but is there any way to simulate dropped connection for TFTP? Possibly shutting TFTP server down would make it, but is this fine for this test machine?

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-09-27