cURL / Mailing Lists / curl-library / Single Mail


Re: segfault after curl_easy_cleanup via progress callback

From: Dave Reisner <>
Date: Wed, 10 Aug 2011 20:07:58 -0400

On Wed, Aug 10, 2011 at 06:48:23PM -0400, Dave Reisner wrote:
> Hi all,
> I received a bug report with backtrace [1] for a curl powered app that I
> work on. It shows a segfault in a progress callback, which is triggered
> _after_ curl_easy_cleanup has been called. Unfortunately, I can't
> reproduce this, and it's still a development version of pacman with a
> limited userbase. There's a half dozen devs using this on a daily basis,
> and this is a routine operation that one of us would have surely run
> into by now.
> That said, the bug reporter was able to find another bug report[2] with
> a very similar backtrace. Note that this bug report uses an earlier
> version of curl, I believe 7.20, while we're using 7.21.7.
> The documentation for curl_easy_cleanup states that further calls to the
> handle are invalid after this call so I'm a bit confused as to why curl
> would be hitting the progress callback at this point. This indirectly
> _insists_ that the application touches the handle. Am I misunderstanding
> the expectation of curl_easy_cleanup that it's _possible_ due to an
> unfinished transfer that the progress callback may be hit one final
> time?
> In case it's relevant, I'll point to the where the majority of our curl
> implementation lies [3], but I'm somewhat confident that pacman "does
> the right thing" here.
> If anyone can point me in the right direction, I've be hugely
> appreciative.
> Thanks,
> Dave Reisner
> [1]
> [2]
> [3]

And just to reply to myself for an added tidbit, it seems in looking
through some stack traces of my own, that this could only occur in the
ftp code path, as http never touches Curl_pp_easy_statemach(). That
would help explain why I've not been able to reproduce yet, as I usually
favor http servers over ftp.


List admin:
Received on 2011-08-11