From abfa8370c0009e415ef2fa97b96c8b042002d92a Mon Sep 17 00:00:00 2001 From: Dave Reisner Date: Sun, 9 Oct 2011 23:03:04 -0400 Subject: dload: unhook error buffer after transfer finishes Similar to what we did in edd9ed6a, disconnect the relationship with our stack allocated error buffer from the curl handle. Just as an FTP connection might have some network chatter on teardown causing the progress callback to be triggered, we might also hit an error condition that causes curl to write to our (now out of scope) error buffer. I'm unable to reproduce FS#26327, but I have a suspicion that this should fix it. Signed-off-by: Dave Reisner Signed-off-by: Dan McGee --- lib/libalpm/dload.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'lib/libalpm/dload.c') diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c index 33824be8..83060f97 100644 --- a/lib/libalpm/dload.c +++ b/lib/libalpm/dload.c @@ -377,8 +377,11 @@ static int curl_download_internal(struct dload_payload *payload, /* perform transfer */ payload->curlerr = curl_easy_perform(curl); - /* immediately unhook the progress callback */ + /* disconnect relationships from the curl handle for things that might go out + * of scope, but could still be touched on connection teardown. This really + * only applies to FTP transfers. See FS#26327 for an example. */ curl_easy_setopt(curl, CURLOPT_NOPROGRESS, 1L); + curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, (char *)NULL); /* was it a success? */ switch(payload->curlerr) { -- cgit v1.2.3-24-g4f1b