On Fri, 28 Jan 2011, ÷ÓÅ×ÏÌÏÄ îÏ×ÉËÏ× wrote:

>> Failed test cases with the threaded resolver:
>> 532 536 573
> No fails are reproduced on my hosts:

Did you use 'configure --enable-debug' before you ran the tests? With your
second patch, I got the threaded resolver version to fail on these:

526 527 530 555 575

... while the c-ares version now did fine all the way.

> My changes for the threaded resolver itself are cosmetics only

...

> Anyway, there should be a way to reproduce these problems more reliable ...
> and ensure that the old code doesn't fail same tests ...

I can indeed confirm that the old code also fails on these tests at times. I
fear that the simple memdebug system is at fault here too as it is a bit
naively assuming single-threaded operations. :-/

I saved a 'memdump' trace from such a failure and I can see perfectly well
that this is indeed what happens. Both threads allocate memory and the
memdebug log saves them not in the order A-malloc, B-free, C-malloc, D-free
but instead it saces the two allocations A and C before the first free B and
that makes 'memanalyze' to freak out.

>> - waitperform(conn, timeout_ms);
>> + Curl_is_resolved(conn,&temp_entry);

> fixed, but I am not sure that this call is used somewhere in the test suite
> ... on the other hand this call is used inside a library itself, but in very
> special case.

Yes? Like in *every single request* when the easy interface is used and
libcurl is built to use c-ares. It wouldn't trigger a test failure since we
don't have any ways in the test suite to detect such errors.

> Amount of my time allocated for this job is almost exhausted. Hope, the
> result is useful.

Thanks, I'll try to make something out of it.

-- 
  / daniel.haxx.se

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-01-30