Hi
I've discovered a memory leak which happens every time the connection
times out while trying to connect to the DNS server. It looks like the
default resolver using signals aren't able to clean up when aborting in
the middle of getaddrinfo().

Because our use case needs a very short timeout (10 seconds) the call to
getaddrinfo() does not fail before the curl-timer fire. This memory leak
disappears if we set the timeout to about 25 seconds.

Will this be fixed by changing to the c-ares resolver?
If so, are there any downsides to using it?

To recreate the memory leak, change your resolv.conf to point to an IP
address that is unreachable, then run the attached program through
valgrind.

Example output:

$ ~/local/src/curl_leak$ valgrind --leak-check=full ./resolv_leak
==4190== Memcheck, a memory error detector
==4190== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==4190== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==4190== Command: ./resolv_leak
==4190==
libcurl/7.40.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25
==4190==
==4190== HEAP SUMMARY:
==4190== in use at exit: 376 bytes in 4 blocks
==4190== total heap usage: 3,885 allocs, 3,881 frees, 216,952 bytes
allocated
==4190==
==4190== 288 bytes in 1 blocks are definitely lost in loss record 4 of 4
==4190== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==4190== by 0x51D0688: make_request (check_pf.c:214)
==4190== by 0x51D0A09: __check_pf (check_pf.c:271)
==4190== by 0x518D4D6: getaddrinfo (getaddrinfo.c:2386)
==4190== by 0x4E85640: curl_dogetaddrinfo (curl_addrinfo.c:555)
==4190== by 0x4E84C80: Curl_getaddrinfo_ex (curl_addrinfo.c:131)
==4190== by 0x4E7EC7F: Curl_getaddrinfo (hostip6.c:212)
==4190== by 0x4E3C187: Curl_resolv (hostip.c:486)
==4190== by 0x4E3C466: Curl_resolv_timeout (hostip.c:664)
==4190== by 0x4E61453: resolve_server (url.c:5129)
==4190== by 0x4E629DD: create_conn (url.c:5755)
==4190== by 0x4E62CE0: Curl_connect (url.c:5862)
==4190==
==4190== LEAK SUMMARY:
==4190== definitely lost: 288 bytes in 1 blocks
==4190== indirectly lost: 0 bytes in 0 blocks
==4190== possibly lost: 0 bytes in 0 blocks
==4190== still reachable: 88 bytes in 3 blocks
==4190== suppressed: 0 bytes in 0 blocks
==4190== Reachable blocks (those to which a pointer was found) are not shown.
==4190== To see them, rerun with: --leak-check=full --show-reachable=yes
==4190==
==4190== For counts of detected and suppressed errors, rerun with: -v
==4190== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 10 from 6)

-- 
Ståle Kristoffersen

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html