Further experiments seem to confirm a bug in host_callback(),
as reported by valgrind:

==7430== Invalid read of size 4
==7430== at 0x812DB13: Curl_resolv_unlock (hostip.c:379)
==7430== by 0x81332B8: Curl_done (url.c:3231)
==7430== by 0x812D55E: curl_multi_perform (multi.c:511)
==7430== by 0x806F355: Retrieve(void) (crawlNT.cpp:889)
==7430== by 0x8070185: main (crawlNT.cpp:1035)
==7430== by 0x42017498: __libc_start_main (in /lib/i686/libc-2.2.5.so)
==7430== by 0x804F570: (within /project/IXE/ixe/crawler/crawlNT)
==7430== Address 0x41E62964 is 8 bytes inside a block of size 12 free'd
==7430== at 0x40027DAB: free (vg_replace_malloc.c:231)
==7430== by 0x812CC51: hash_element_dtor (hash.c:62)
==7430== by 0x8139F8C: Curl_llist_remove (llist.c:136)
==7430== by 0x812CF39: Curl_hash_clean_with_criterium (hash.c:260)
==7430== by 0x812D86F: hostcache_prune (hostip.c:193)
==7430== by 0x812D924: cache_resolv_response (hostip.c:258)
==7430== by 0x812DE36: host_callback (hostip.c:555)
==7430== by 0x8141A45: end_hquery (ares_gethostbyname.c:145)

In fact, I commented out the call to hostcache_prune() in
cache_resolv_response()
and the bug has disappeared.

I am now trying a modified version of host_callback() that invokes
ares_cache_resolv_response(), a version of
cache_resolv_response() without the call to hostcahce_prune().

So far also this version seems to work: it has been running for over
an hour without crashing.

A proper fix requires a better understanding than mine of the relationships
between ares and the host cache.

-- 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-13