On Thu, 4 Sep 2003, Jeff Pohlmeyer wrote:

> I am trying to run curl_multi on a separate thread from inside a gtk
> program. ( Currently it is about 11,000 lines of pascal-flavored spaghetti.
> )
>
> I keep getting a lot of SIGSEGV's that look like the one below.

I can't say I realize what the problem is, nor have I seen it before.

> These crashes don't always occur in exactly the same place every time, but
> it is almost always when some function in hostip.c calls some function in
> hash.c , and passes it a 0xFFFFFFF pointer.

> Curl_hash_clean_with_criterium (h=$83a6948, user=$bf7ff370,
> comp=$4005d340 <hostcache_timestamp_remove at hostip.c:170>) at
> hash.c:248
>
> 248 if (comp(user, ((curl_hash_element *) CURL_LLIST_VALP(le))->ptr)) {
>
> (gdb) print le
> $1 = (^curl_llist_element) $fffffffd

This shows that at this point the hash is damaged. The 'le' should be a
pointed to a valid list element struct.

I've taken some time to "demacrofy" the hash.c source a bit to better
understand it (commit pending), and the above line has then been converted to:

     curl_hash_element *he = le->ptr;
     if (comp(user, he->ptr)) {

... which doesn't explain much more in this case though, since 'le' itself is
bad!

This looks like a case of memory being overwritten, but it is really hard for
me to say that this is a libcurl matter or something your application does by
itself.

I guess you can't repeat this problem with a much smaller and stand-alone
plain-C program?

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf