Menu
▾
▴
#1191 When using a wrong hostname in --interface, the wrong host name appears in the error message
While testing my patch for #1189 I discovered a related problem which is pre-existing: I can reproduce it on the current git master. For test 1084, even though the exit code is correct (45, CURLE_INTERFACE_FAILED) the error text is wrong and confusing:
src/curl --interface DoesNotExist.example.com http://www.google.com/
curl: (45) Could not resolve host: www.google.com (Domain name not found)
Actually it failed to resolve DoesNotExist.example.com, not www.google.com like the error message says. If you use --proxy then the error message says "Could not resolve proxy" which is also not true.
I am not sure what the best way to fix this would be (I can think of a hack or two), but I just wanted to document it single I noticed it.
ACK. I'll see what I can do about it...
I've a similar error using this piece of PHP code
$url = "http://willneverexist42";$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_exec($ch);
var_dump(curl_error($ch));
var_dump(curl_errno($ch));
curl_close($ch);
?>
Expected is something like
string(55) "Could not resolve host: (willneverexist42); Host not found"
Currently the error message
string(45) "Could not resolve host: (nil); Host not found"
This happens when php is compiled with 7.29.0 and master as well, but pass on 7.27.0 (and below i suppose). Windows only.
I'm not a cURL developer but I created this bug report so I am going to take a look at it :-)
This is a different issue than the one I brought up.
Actually, Anatol, your issue is not MS Windows only. Rather, it is specific to the threaded resolver.
The problem was revealed in commit c43127414d89ccb9ef6517081f68986d991bcfb3, due to changes in the way the multi interface is used (I think) but it is not the fault of that change. The fault was already present in lib/asyn-thread.c : it attempts to use the hostname in the error message after it has already been freed.
The attached patch will get rid of your problem.
It looks like my patch didn't make it into the ticket? Here it is again, and inline as well. Sorry for the duplication.
--- a/lib/asyn-thread.c
+++ b/lib/asyn-thread.c
@@ -518,12 +518,13 @@ CURLcode Curl_resolver_is_resolved(struct connectdata *conn,
if(done) {
getaddrinfo_complete(conn);
- destroy_async_data(&conn->async);
if(!conn->async.dns) { resolver_error(conn, "host");return CURLE_COULDNT_RESOLVE_HOST;
}
*entry = conn->async.dns;
}
else {
Thanks Kim, I based the fix on your patch but I modified it slightly before I pushed it. You can see it git now. But I agree that this fix doesn't really change what this bug is originally about.
btw, this --interface bug only shows when libcurl is built with c-ares as the resolver backend, both the threaded and stock resolver backends work fine. See tests with current git HEAD:
threaded:
./src/curl --interface iamwrong.moo.com localhost
curl: (45) Could not resolve host: iamwrong.moo.com
c-ares:
./src/curl --interface iamwrong.moo.com localhost
curl: (45) Could not resolve host: localhost (Domain name not found)
stock-resolver:
./src/curl --interface iamwrong.moo.com localhost
curl: (45) Couldn't bind to 'iamwrong.moo.com'
Kim, I'm not a curl dev as well, would have to become one if Daniel were not that fast :)
The ticket was just looking very similar and I didn't want to duplicate.
Daniel, many thanks for the fast fix. I'm going to test the same on windows and to extract c code for a test.
Here's the code produced using --libcurl with a vc11/x86 build of 7.29.0 concerning that 'nil' issue. After applying the patch the issue disappears. The build options used
nmake /f Makefile.vc mode=static VC=11 WITH_DEVEL=c:\vc11_deps\repo\curl_deps.x86 WITH_SSL=dll WITH_ZLIB=static WITH_SSH2=static ENABLE_WINSSL=no USE_IDN=no GEN_PDB=yes DEBUG=no MACHINE=x86
lowering importance since this is "just" a wrong error message
Thanks for your report. It took a long time but now I've committed and pushed a fix for this as commit ad47d8e263939a81.
I consider this issue closed and dealt with!