Having been recently looking at code in this neighborhood, could you
check conn->async.dns?

> +#if defined(USE_ARES)

 if(!conn->async.dns) {

> + ares_cancel(conn->data->state.areschannel);

}

> +#endif

Jason

Daniel Stenberg wrote:

> On Thu, 4 Aug 2005, Harshal Pradhan wrote:
>
>> I really don't know much about the ares API and how ares is used in
>> curl. On a random hunch, I tried the following
>
>
> ...
>
>> +#if defined(USE_ARES)
>> + ares_cancel(conn->data->state.areschannel);
>> +#endif
>
>
> ...
>
>> So, getting to the point .... I have lots of questions: Has anyone
>> encountered such a problem earlier? Has there been any work on a
>> similar issue in later versions of curl? Is my reasoning above sane?
>> Does the my "random hunch" patch above make any sense at all?
>
>
> Thanks for this.
>
> I believe you are right on track, that there is a pending callback
> that gets called after the connectdata struct has been freed and thus
> it causes havoc. This is still so in the CVS version.
>
> However, this fix of yours blindly assumes that there is a pending
> ares request for this connect data that we should cancel. When the
> multi interface is used, the same ares 'channel' is used for name
> resolves for all easy handles so this can most probably mistakenly
> cancel a name resolve request for another handle if you have a bad day.
>
> I think we need to make sure that we only cancel actual callbacks for
> this particular connect struct... But there's no really good API for
> this in ares of today! I think we need to figure out and implement one.
>
> I'm open for (other) ideas on how this could be done.
>
Received on 2005-08-04