Menu
▾
▴
#874 Curl_dns_entry leaked on redirect + connect failure
closed-fixed
5
2013-06-21
2009-11-04
No
How to repro:
1. Set up a first web server that redirects (307) to a http://server:port that's down
2. Have curl connect to the first web server using curl multi
After the curl_easy_cleanup call, there will be curl dns entries hanging around with in_use != 0.
Working on a patch...
disconnet_conn = true in multi_runsingle but Curl_done is not always called - which would clean up the conn->dns_entry. Don't know if it's safe to call Curl_done so instead I cleanup in disconnect_conn clause no matter what.
Also, maintain invariant in ConnectPlease that if it returns an error then conn->dns_entry == NULL to avoid double unlocks.
New patch attached.
Clean up in Curl_disconnect. Along with plugging the DNS ref leak in multi.c, this allows us to simplify Curl_connect too.
And for what it's worth, the patch fixes test cases 311 and 312 which now have memory leaks because of recent DNS hostcache behavior change.
When applied, test 19 fails with a memory leak (if configure --enable-debug was used):
test 019...[attempt connect to non-listening socket]
** MEMORY FAILURE
Leak detected: memory still allocated: 60 bytes
At 836e2e4, there's 16 bytes.
allocated by curl_addrinfo.c:156
At 836e2b4, there's 32 bytes.
allocated by curl_addrinfo.c:137
At 836e384, there's 12 bytes.
allocated by hostip.c:344
- abort tests
Fix DNS leaks
This one fixes the leaks by setting conn->dns_entry early and cleaning it up in Curl_disconnect.
Setting conn->dns_entry early means it doesn't have to be passed around everywhere.
Passes all tests I could run (no libssh2) including #19
Thanks for the report, this problem is now fixed in CVS!