On Fri, 28 Jan 2011, Всеволод Новиков wrote:
Failed test cases with the threaded resolver: 532 536 573No 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
