On Mon, 25 Nov 2002, Abe Lederman wrote:

[comments follow inlined]

> I the stack trace that I sent yesterday:
>
> *e = {ptr = 0xcc188, prev = 0x0, next = 0xffffffff}
>
> so the segfault is occurring trying to execute:
>
> e->prev->next = e->next;

That next pointer has obviously been set very bad.

> *list at this point is:
>
> {head = 0xffffffff, tail = 0xcfb08, dtor = 0x137f8
> <_hash_element_dtor>, size = 1}

Hm, that is odd. That list pointer points to the same struct we found this
particular 'e' from. As in:

    le = CURL_LLIST_HEAD(h->table[i]);
    while(le != NULL)
      if (comp(user, ((curl_hash_element *) CURL_LLIST_VALP(le))->ptr)) {
        lnext = CURL_LLIST_NEXT(le);
        Curl_llist_remove(h->table[i], le, (void *) h);

Since 'h->table[i]->head' is damaged when that Curl_llist_remove() is called,
it must've been destroyed since the first line above was called since that
too used the 'h->table[i]->head' field and then it must've worked!

> A second segfault that occurred yesterday is at:
>
> comp=0x13dc8 <hostcache_timestamp_remove>) at hash.c:269
> 269 if (comp(user, ((curl_hash_element *)
> CURL_LLIST_VALP(le))->ptr)) {
> (gdb) where
> #0 Curl_hash_clean_with_criterium (h=0x48c10, user=0xf680f920,
> comp=0x13dc8 <hostcache_timestamp_remove>) at hash.c:269
> #1 0x13e20 in hostcache_prune (hostcache=0x48c10, cache_timeout=60,
> now=1038159021)
> at hostip.c:189
>
> Examining some of the variables where the segfault occurred here is what I
> get:
>
> i = 2
> *h = {table = 0xcae28, dtor = 0x13f70 <Curl_freeaddrinfo>, slots
> = 7, size = 8}
>
> le = (curl_llist_element *) 0xffffffff

And this is I guess, because the 'h->table[i]->head' contained 0xffffffff
when the line

   le = CURL_LLIST_HEAD(h->table[i]);

was executed (where i was 2).

So, at times it seems the 'h->table[i]->head' field can get set to an invalid
value. Perhaps always 0xffffffff.

The fact that you never saw this using only a single thread indicates that
this is related to multiple threads. Also, I would say, since this
linked-list fiddling is made on handle-specific data, they *should* not
behave differently when used single- or multi-threaded since they should only
be used in one thread at a time anyway.

Are 100% sure that you only use one handle in one thread at all times?

This is really hard to understand and to track down unless we can come up
with a way to reproduce the problem.

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en