curl-library
Re: Crash on shared asynchronous resolver results
Date: Fri, 02 Sep 2011 20:43:10 +0400
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
Received on 2011-09-02