cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Crash on shared asynchronous resolver results

From: Всеволод Новиков <novikov_at_doroga.tv>
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