Anyway, some very strange obvious circumstances are leading to the crash:
   - libcurl: asynchronous result return
   - underlining posix-style system: two simultaneous connection
notifications immediately before the poll()

There are lot of asynchronous result returns - no crash
There are lot of two simultaneous connection notifications immediately
before the poll() - no crash

But if THE BOTH happen - it leads to the crash. Sometimes the crash
happens immediately after the application start. In other cases - after
many circles of the test, creating and removing lot of easy and multi
handles.

I've fixed my workaround described before, which passes addresses
instead of host names to the libcurl. Now it looks working fine always.
It means that the bug may be hidden in the code using asynchronous
resolver. But I didn't find any suspicious code.

I've reported the issue to the underlining platform developers. They
have answered that they also didn't find any suspicious in the
underlining subsystem.

I really don't know who is responsible for the crash, until now. I've
spent already 3 weeks and can't spend more. I am going to use the
workaround in my application.

Shortly investigation results are:
   - I am sure that the DNS cache is not a source of the bug - I've
switched it off without noticeable results.
   - I am sure that the connection cache is not a source of the bug -
I've switched it off without noticeable results.
   - I am sure that the share interface is not a source of the bug -
I've switched it off without noticeable results.
   - I am sure that my source code is not a source of the bug - the
fine-working workaround uses mainly the same code.
   - I am sure that the underlining resolver itself is not a source of
the bug - the same results have had been got with c-ares, my fake-ares,
and hardcoded address returned in asynchronous manner

I think that some inconsistencies may happen in different ways of
synchronous and asynchronous results processing. F.e. I've noticed that
async.dns is not cleared at the moment of the connection start in case
of synchronous result, while it is cleared if the asynchronous result is
used. This particular case is not a problem, but some other such
inconsistencies may lead to the problem.

I also can not exclude a problem in the underlining posix subsystem, but
I have no idea how it may depend on synchronous/asynchronous results of
resolving passed to the libcurl.

Regards,
Vsevolod

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