Menu

#725 Error buffer not filled on CURLE_COULDNT_RESOLVE_HOST

closed-fixed
5
2013-06-21
2008-02-07
Patrick_
No

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.

Discussion

  • Patrick_

    Patrick_ - 2008-02-07

    Bug demonstration code in C

     
  • Daniel Stenberg

    Daniel Stenberg - 2008-02-08

    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.

     
  • Daniel Stenberg

    Daniel Stenberg - 2008-02-08
    • status: open --> open-works-for-me
     
  • Patrick_

    Patrick_ - 2008-02-08

    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.

     
  • Yang Tse

    Yang Tse - 2008-02-08

    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 ?

     
  • Patrick_

    Patrick_ - 2008-02-08

    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.

     
  • Daniel Stenberg

    Daniel Stenberg - 2008-02-08

    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.

     
  • Daniel Stenberg

    Daniel Stenberg - 2008-02-08
    • status: open-works-for-me --> open-accepted
     
  • Yang Tse

    Yang Tse - 2008-02-09

    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;

     
  • Patrick_

    Patrick_ - 2008-02-09

    Logged In: YES
    user_id=1273052
    Originator: YES

    Great, that fixed it. Thanks a lot!

     
  • Yang Tse

    Yang Tse - 2008-02-10

    Logged In: YES
    user_id=1590006
    Originator: NO

    Fix committed to CVS

     
  • Daniel Stenberg

    Daniel Stenberg - 2008-02-11

    Logged In: YES
    user_id=1110
    Originator: NO

    Thanks to both of you! Case closed.

     
  • Daniel Stenberg

    Daniel Stenberg - 2008-02-11
    • status: open-accepted --> closed-fixed