Daniel,

I've tried to make some workaround, avoiding resolve logic in the
libcurl. I've implemented some kind of my own DNS cache. Also I've
switched the redirect feature off and implemented my own redirects. Now
the libcurl gets all requests with stringfied address on the place of
the host in the url, and additional "Host:..." header in my example.

These changes help me to keep the stack live, but some memory
destruction happens anyway. Now the mult-handler internal DNS cache
appears to be broken at some indefinite moment. As a result, all
consequent requests are failed because they are getting wrong address
from the cache - it is used even the only address, not domain name,
appears in the request url.

Please tell me, may I switch using internal DNS cache off at all? It
looks suspiciously that all crashes obviously concern the DNS cache.
I would like to switch the internal DNS cache off at all and try to use
libcurl without it.

Regards,
Vsevolod

02.09.2011 20:43, Всеволод Новиков пишет:
> Hi Daniel,
>
> I should fix some my sentences in the letter before. Really, even if
> no any shared members, internally or externally, are used, the crash
> happens anyway.
>
> I am using the example which creates separate multi-handles, one per
> one easy-handle, and doesn't create a share handle at all. As I
> understand, it means that there are no any shared members between
> handles.
>
> I am using also my own resolver, simulating c-ares interface, with
> some kind of internal DNS cache added there today.
>
> Then the application crashes exactly in the same circumstances:
> - one connection, being in WAITRESOLVE state, has just got the
> asynchronous resolver result, makes connect() call and gets EINPROGRESS
> - the connection makes pull() call, gets no events, and goes from
> WAITRESOLVE to WAITCONNECT state
> - another connection (to the same host), which has just been
> created, immediately gets the cached resolver result, makes connect()
> call and gets EINPROGRESS
> - the second connection makes a pull() call, which destroys a stack
> for unknown reason
>
> What is noticeable: I've never got a crash when two connections are
> getting immediate cached results from the resolver yet. It looks
> obvious - one connection should get asynchronous result being in
> WAITRESOLVE state, while other - immediate from cache being in the
> CONNECT state. Secondary - the both connections involved in this
> crash, was always looking to the same domain name (in the example,
> while server IP is always the same, domain names may be different -
> because of 301/302 relocations).
>
> Regards,
> Vsevolod
>
> 02.09.2011 01:43, Daniel Stenberg пишет:
>> On Thu, 1 Sep 2011, Всеволод Новиков wrote:
>>
>>> I've met irregular application crash in case of sharing DNS entries
>>> when the asynchronous (c-ares particularly) resolver is used.
>>> Unfortunately, I can not yet reproduce the crash on "big" platform
>>> like linux or windows.
>>
>> IMHO, you should really focus on getting the problem to repeat on
>> linux so that you can use valgrind etc to track it down.
>>
>> Until then I can only suggest that you add more printf()s to get
>> knowledge about states in the functions immediately before the crash.>
>>
>
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html

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