On Fri, 24 May 2002, Avery Fay wrote:

> I compiled libcurl and my program with -O0 (for no optimization). Here are
> the new traces.

Great! These ones look a lot better and the details sure can reveal a lot...
I might have a suggestion on where to check for further details on this.

> 0x4004bb92 in Curl_hash_clean_with_criterium (h=0x8170e10, user=0xbdbff7ec,
> comp=0x4002fae8 <_curl_hostcache_timestamp_remove>) at hash.c:267
> 267 le = CURL_LLIST_HEAD(h->table[i]);
> (gdb) bt
> #0 0x4004bb92 in Curl_hash_clean_with_criterium (h=0x8170e10,
> user=0xbdbff7ec, comp=0x4002fae8 <_curl_hostcache_timestamp_remove>)
> at hash.c:267

What if you check that h->table[i] entry? I suspect that the entry in there
is bad and that the macro "CURL_LLIST_HEAD" reads bad memory. Or similar.

We can see that the second trace is a very similar crash. It would be *very*
useful to see a few variables' contents here. 'info locals' for example.

> #0 0x400c0a3b in free () from /lib/libc.so.6
> #1 0x4002fd5f in Curl_freeaddrinfo (freethis=0x8053ee0) at hostip.c:264
> #2 0x4004b5f8 in _hash_element_dtor (user=0x8068be8, element=0x8069578)
> at hash.c:66
> #3 0x4004b42a in Curl_llist_remove (list=0x8068c68, e=0x80695a0,
> user=0x8068be8) at llist.c:134
> #4 0x4004bbe9 in Curl_hash_clean_with_criterium (h=0x8068be8,
> user=0xbf7ff7ec, comp=0x4002fae8 <_curl_hostcache_timestamp_remove>)
> at hash.c:271

This one just got a little further. The data pointed to by the table[i] was
ok, so it called Curl_llist_remove() that ends up calling Curl_freeaddrinfo()
but then it dies on free() since it passes in data that is bad.

It sure looks as if the DNS cache pruning code is involved in this crash.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm