curl-library
RE: Segfault running a threaded application
Date: Tue, 26 Nov 2002 13:32:18 +0100 (MET)
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?palm0002enReceived on 2002-11-26