Bugs item #2884791, was opened at 2009-10-23 17:56
Message generated for change (Settings changed) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2884791&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: name resolving/DNS
Group: crash
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Steve Chan (schan8)
Assigned to: Daniel Stenberg (bagder)
Summary: Curl_llist_insert_next crash (7.19.5)

Initial Comment:
Hi,

This might be related to #1833734: When running load tests with libcurl, my application is randomly crashing. It looks like a datarace from the callstack:

> libcurl.dll!Curl_llist_insert_next(curl_llist * list=0x17798e60, curl_llist_element * e=0x00000000, const void * p=0x14237d50) Line 77 + 0x5 bytes C
         libcurl.dll!Curl_hash_add(curl_hash * h=0x17798e60, void * key=0x13db0d20, unsigned int key_len=15, void * p=0x00cb3a30) Line 162 + 0x1e bytes C

Although the next element, e, in the callstack's param values is NULL, inside Curl_llist_insert_next, list->size is non-zero and has branched to the statement, ne->next = e->next. Looking at list argument, list->tail is no longer NULL as well, even though we had originally called,

if(Curl_llist_insert_next(l, l->tail, he)) {.

passing l->tail as the parameter e.

This crash is in the gethostbynamethread, and I can see the only other thread that accesses Curl_hash_add is in Curl_sh_entry for multi.c. Both thread were likely adding the "localhost:3128" dns entry (that is what I see in the gethostbynamethread).

Am I missing some synchronization (I can see that the hostname thread does an acquire [acquire_thread_sync(&tsd)])? I have the core dump saved if you need more information.

Thanks,
Steve

----------------------------------------------------------------------

Comment By: Steve Chan (schan8)
Date: 2009-11-02 17:26

Message:
Thanks for the update! Registering a lock/unlock handler is currently
passing our load test so we'll be doing that approach for now.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2009-10-30 23:42

Message:
This problem will hopefully be addressed with the work I already mentioned.
Planed for inclusion in the main code after the 7.19.7 release.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2009-10-25 19:32

Message:
Let me quote docs/KNOWN_BUGS:

64. The threaded resolver used in libcurl on Windows has some kind of
race
  problem when multiple simultanoes resolves are done, like with the
multi
  interface transferring many files in parallell:
  http://curl.haxx.se/mail/lib-2009-04/0028.html

There have been some work on a fix for this, but very few windows people
have joined in to comment or help so the progress has been slow.
Constantine Sapuntzakis posted a lat version of his work on this to the
curl-library list on Sep 26:

http://curl.haxx.se/mail/lib-2009-09/0316.html

I'm sure he'd appreciate someone else joining in to help and to test and
suggest.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2884791&group_id=976
Received on 2009-11-05