Another memory bug detected by valgrind:

==15419== Invalid read of size 4
==15419== at 0x81339CF: Curl_do (url.c:3318)
==15419== by 0x812D91F: curl_multi_perform (multi.c:423)
==15419== by 0x806F50D: Retrieve(void) (crawlNT.cpp:892)
==15419== by 0x807033D: main (crawlNT.cpp:1038)
==15419== Address 0x49995F60 is 796 bytes inside a block of size 1648
free'd
==15419== at 0x40027DAB: free (vg_replace_malloc.c:231)
==15419== by 0x813174D: Curl_disconnect (url.c:1340)
==15419== by 0x81338FC: Curl_done (url.c:3255)
==15419== by 0x8133982: Curl_do (url.c:3292)
==15419==

One problem seems due to Curl_do() in url.c.
After Curl_done(), the old conn has been freed, so it should
no longer be used. Curl_connect() creates a new one in *connp.
Below I have added the assignement conn = *connp:

      if(CURLE_OK == result) {
        bool async;
        /* Now, redo the connect and get a new connection */
        result = Curl_connect(data, connp, &async);
+ conn = *connp; /* it is a new connection */
        if(CURLE_OK == result) {
          /* We have connected or sent away a name resolve query fine */

          if(async) {
            /* Now, if async is TRUE here, we need to wait for the name
               to resolve */
            result = Curl_wait_for_resolv(conn, NULL);
            if(result)
              return result;

            /* Resolved, continue with the connection */
            result = Curl_async_resolved(conn);
            if(result)
              return result; /* failed */
          }

However this still does not explain how the freed connection
survives and gets used again in curl_multi_perform().

-- Beppe

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Received on 2003-12-14