I still have problems of corruption of an llist
in a mulithreaded, multihandle cURL application.
It occurs in:

(gdb) where
#0 Curl_hash_clean_with_criterium (h=0x81e13c8, user=0xbf7ff4ac,
    comp=0x81165d8 <hostcache_timestamp_remove>) at hash.c:261
#1 0x08116624 in hostcache_prune (hostcache=0x81e13c8, cache_timeout=300,
    now=1070238892) at hostip.c:193
#2 0x081166d9 in cache_resolv_response (data=0x852f530, addr=0x99db310,
    hostname=0x85bd7e8 "www.buechertipp24.de", port=80) at hostip.c:258
#3 0x08116beb in host_callback (arg=0x84383d0, status=0, hostent=0x86c5fc0)
    at hostip.c:555
#4 0x0812a86a in end_hquery (hquery=0x85bd808, status=0, host=0x86c5fc0)
    at ares_gethostbyname.c:145
#5 0x0812a829 in host_callback (arg=0x85bd808, status=0,
    abuf=0xbf7ff64c "ß\024\201\200", alen=103) at ares_gethostbyname.c:134
#6 0x0812ca93 in end_squery (squery=0x82bf360, status=0,
    abuf=0xbf7ff64c "ß\024\201\200", alen=103) at ares_search.c:175
#7 0x0812ca6f in search_callback (arg=0x82bf360, status=0,
    abuf=0xbf7ff64c "ß\024\201\200", alen=103) at ares_search.c:168
#8 0x0812d65b in qcallback (arg=0x85bd820, status=0,
    abuf=0xbf7ff64c "ß\024\201\200", alen=103) at ares_query.c:103
#9 0x0812c7c6 in end_query (channel=0x871b498, query=0x8290818, status=0,
    abuf=0xbf7ff64c "ß\024\201\200", alen=103) at ares_process.c:583
#10 0x0812c06c in read_udp_packets (channel=0x871b498, read_fds=0xbf7ff94c,
    now=1070238892) at ares_process.c:246
#11 0x0812bc7e in ares_process (channel=0x871b498, read_fds=0xbf7ff94c,
    write_fds=0xbf7ff8cc) at ares_process.c:60
#12 0x081169bd in Curl_is_resolved (conn=0x84383d0, dns=0xbf7ffa00)
    at hostip.c:454
#13 0x081160c7 in curl_multi_perform (multi_handle=0x81e1fa0,
    running_handles=0x81e1a4c) at multi.c:375

This time, the last element is corrupted, and contains 0xffffffff
instead of 0x0:

(gdb) p *list
$17 = {head = 0x81f0d20, tail = 0x8602e20,
  dtor = 0x81159b4 <hash_element_dtor>, size = 13}
(gdb) p *list->tail
$18 = {ptr = 0x8538b70, prev = 0x8538f70, next = 0xffffffff}

I am quite hopeless, since the problem occurs occasioanlly
after several tens of thousands transfers and so it is hard to reproduce.
I have run the application through valgrind and it didn't find
any errors or memory leaks.

-- Beppe

PS. I am not using the CURLOPT_DNS_USE_GLOBAL_CACHE option.

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
Received on 2003-12-01