On Sat, 2 Feb 2008, Christian Buchner wrote:

> I have a single threaded win32 application performing about 20 simultaenous
> HTTP requests to servers with the curl multi interface. It will access
> several servers at once (by means load balancing through different
> subdomains), sometimes requiring multiple host name resolutions at about the
> same time.
>
> I recently upgraded to curl-7.18.0 and encountered a crash in module
> llist.cin the function Curl_llist_insert_next() The argument e passed to the
> function was NULL and the statement ne->next = e->next caused an invalid
> memory access.

Thanks for your fine analysis!

Since the threaded resolver has been identical for a while and it has not been
changed in 7.18.0 - in fact it's been the same since 7.16.3 and basically the
same since 7.16.1 - this has to be a problem that's been around for a while.

> I suspect a race condition among multiple resolver callbacks happening in
> rapid succession, because when I set the program counter (PC) into the
> calling function and re-executed the Curl_llist_insert_next() function call,
> the variable passed to the function was no longer NULL and no crash occured
> on the second attempt.
>
> Adding mutexes for protecting these lists while the callback accesses them
> might therefore prevent a crash.

I can only agree. But I'm not a win32 man so I'm not the right person to even
start to fix this problem.

> I will try witching to the non-threaded and synchronous gethostbyname()
> resolver until this issue is fixed in libcurl.

In general I'd say using c-ares is the coolest resolver in libcurl, especially
for the multi interface since that'll allow asynchronous name resolves without
running extra threads for each.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html