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
