cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: crash using libcurl 7.19 multi interface

From: Hendrik Schober <spamtrap_at_gmx.de>
Date: Fri, 13 Mar 2009 13:38:29 +0100

Daniel Stenberg wrote:
> On Fri, 13 Mar 2009, Hendrik Schober wrote:
>
>>> MT as in multi-threading? Then nope, as the example doesn't use threads...
>> It does. Internally, libcurl creates a bunch of threads for the requests.
>> One of them crashes.
>
> On Windows it creates a thread for the name resolving, that's the only thread
> it creates. Of course, when you do many resolves it'll create one for each as
> long as they are parallel enough to not have gotten stored in the DNS cache.

Yes, that's what I've seen,

>> The stack trace is the very same, every time:
>> libcurld.dll!Curl_llist_insert_next(curl_llist * list=0x01398910,
>> curl_llist_element * e=0x035c8fe0, const void * p=0x036c1098) Line 70 C
>> libcurld.dll!Curl_hash_add(curl_hash * h=0x01398810, void * key=0x03530e88,
>> unsigned int key_len=20, void * p=0x0363d118) Line 162 + 0x14 bytes C
>> libcurld.dll!Curl_cache_addr(SessionHandle * data=0x0154fbd8, Curl_addrinfo
>> * addr=0x0356a5a8, const char * hostname=0x0356aec8, int port=80) Line 368 +
>> 0x1a bytes C
>> libcurld.dll!addrinfo_callback(void * arg=0x0348c0d0, int status=0, void *
>> addr=0x01359490) Line 118 + 0x21 bytes C
>> libcurld.dll!Curl_addrinfo4_callback(void * arg=0x0348c0d0, int status=0,
>> hostent * hostent=0x01359490) Line 154 + 0x11 bytes C
>> libcurld.dll!gethostbyname_thread(void * arg=0x0348c0d0) Line 264 + 0xf
>> bytes C
>
> Ah, and that is indeed the name resolve thread it seems.

Yep, from my poking in the debugger it seems to manage to end
up with an invalid list in 'Curl_llist_insert_next()'. (List's
size is 1, but upon accessing it crashes. If instead I force
it to assume the list is empty, it works.)

> I actually recall others in the past that have claimed there are problems with
> the way the threaded resolver works, but we haven't sorted anything like that
> out. Of course one sensible test to do is to rebuild libcurl to use c-ares or
> the synchronous resolver and see if that removes the crash.

Thanks. I'll be trying to turn asynchronous resolving off then
as the next step. I suppose it's explained somewhere in the dos.

Schobi
Received on 2009-03-13