| commit | abfa8370c0009e415ef2fa97b96c8b042002d92a | |
| author | Dave Reisner <dreisner@archlinux.org> | |
| Mon, 10 Oct 2011 03:03:04 +0000 (9 23:03 -0400) | ||
| committer | Dan McGee <dan@archlinux.org> | |
| Tue, 11 Oct 2011 00:09:59 +0000 (10 19:09 -0500) | ||
| tree | 0a008a2a20112050adaf9177cf4bb459093b6c40 | treesnapshot (tar.gz zip) |
| parent | 8f414cd040aa11957a443ddda42ad14b83733007 | commitdiff |
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 <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
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@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
| lib/libalpm/dload.c | diffblobblamehistory |