With libcurl 7.17.1 and 7.18.0, when adding an easy handle (that has CURLOPT_ERRORBUFFER set) to a multi handle and "performing" the multi handle, if the error code received is CURLE_COULDNT_RESOLVE_HOST, the error buffer is not filled with the corresponding error message. When running the same easy handle with curl_easy_perform(), and the error received is CURLE_COULDNT_RESOLVE_HOST, the error buffer _is_ filled as expected.
Attached is standalone C code which demonstrates the bug.
Bug demonstration code in C
Logged In: YES
user_id=1110
Originator: NO
Sorry, but I can't repeat the problem (using the supplied code) with my current CVS (not too different than 7.18.0 atm). If I make the destination port one that isn't used, or if I use a host name that doesn't resolve I get error messages in both cases.
Logged In: YES
user_id=1273052
Originator: YES
Hmm, that's odd. Are you linking it statically (have -DCURL_STATICLIB defined) and running it on Windows XP (I'm using SP1 at the moment)? I can reproduce this every time. I doubt it will change anything, but try disconnecting your modem and running the code, as the PC I'm running this code on is not connected to the 'net at all.
Logged In: YES
user_id=1590006
Originator: NO
I can reproduce it on W2k with MSVC 6.
On W2k cygwin with gcc 3.4.4 it doesn't fail.
Any direction or additional info or test to debug this ?
Logged In: YES
user_id=1273052
Originator: YES
I'm using MinGW/GCC 3.4.2 (install Dev-C++ 4.9.9.2 to simulate my environment); I'm using the -mms-bitfields compiler flag as well. Linking against curl statically, of course, and my CFLAGS are -Os -s -fomit-frame-pointer. LFLAGS are -lwinmm -lpsapi -lshfolder -lwsock32 -lshell32.
Logged In: YES
user_id=1110
Originator: NO
I did my tests on Linux only, as I don't have any windows systems around to test on.
To debug this, I suggest setting a break-point in the function lib/connect.c:Curl_is_connected() when running Patrick's test case, and then single-step it to see exactly where it returns error and why there's no failf() called for that case.
Logged In: YES
user_id=1590006
Originator: NO
It seems that tis only affects Windows threaded name resolver builds.
Verify if this patch solves the issue for you.
Index: lib/hostthre.c
RCS file: /cvsroot/curl/curl/lib/hostthre.c,v
retrieving revision 1.50
diff -u -r1.50 hostthre.c
--- lib/hostthre.c 5 Nov 2007 09:45:09 -0000 1.50
+++ lib/hostthre.c 9 Feb 2008 04:08:01 -0000
@@ -682,6 +682,8 @@
CURLcode Curl_is_resolved(struct connectdata *conn,
struct Curl_dns_entry **entry)
{
+ struct SessionHandle *data = conn->data;
+
*entry = NULL;
if(conn->async.done) {
@@ -689,6 +691,8 @@
Curl_destroy_thread_data(&conn->async);
if(!conn->async.dns) {
TRACE(("Curl_is_resolved(): CURLE_COULDNT_RESOLVE_HOST\n"));
+ failf(data, "Could not resolve host: %s; %s",
+ conn->host.name, Curl_strerror(conn, conn->async.status));
return CURLE_COULDNT_RESOLVE_HOST;
}
*entry = conn->async.dns;
Logged In: YES
user_id=1273052
Originator: YES
Great, that fixed it. Thanks a lot!
Logged In: YES
user_id=1590006
Originator: NO
Fix committed to CVS
Logged In: YES
user_id=1110
Originator: NO
Thanks to both of you! Case closed.