>> curl_multi_cleanup . Oddly, if I use URLs that contain actual IP addresses instead of
>> the
>>> host names, the leak doesn't happen. This suggests of course that the problem is in
>>> the resolving process, and indeed Process Explorer will show a non-decreasing
>>> number of thread handles. I'm using curl (7.13.2) with VC++ 6.0. but without c-ares
>>> .
>
>
> A change done 14. June address just this (the resolver thread handle wasn't closed).
> Try with a fresh version from CVS and run Process Explorer again.
I've applied the change and indeed the handle leak I reported on was gone. Thanks !

> The other leak, I cannot comment on.
It was a wild bug hunt, but I finally caught the beast I was after.
My original report mentioned that I don't use c-ares with curl. Indeed I don't, but I use
c-ares separately. As it turns out there is a leak in c-ares init sequence. The following
loop for example, will leak exactly N handles (reported by Process Explorer as \Device\TCP
handles)

        for (int i=0; i<N; ++i) {
                ares_channel c;
                if ( ares_init(&c)==ARES_SUCCESS )
                        ares_destroy(c);
        }

I debugged it and as it turns out the call to GetNetworkParams (in the function
get_iphlpapi_dns_info) leaks a handle. That's it. I guess (though I haven't tried it) that
curl with c-ares will suffer from the same problem.

So to summarize:
1. the change to hostthre.c solved one leak
2. the Windows implementation of c-ares has a leak in the call to GetNetworkParams . It
manifests itself as a \Device\TCP handle.

Thanks for the help.

Cheers,
Shmul
Received on 2005-06-28