[pacman-dev] [PATCH 1/2] dload: unhook error buffer after transfer finishes

[Dan McGee]

On Sun, Oct 9, 2011 at 10:35 PM, Dave Reisner <d at falconindy.com> wrote:
> 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 <dreisner at archlinux.org>
> ---
>  lib/libalpm/dload.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c
> index 33824be..e848b30 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 *)0);
0, aka NULL? Don't mix integers and pointers please, and the cast thus
becomes unnecessary.

>        /* was it a success? */
>        switch(payload->curlerr) {
> --
> 1.7.7
>
>
>