Sorry for some inconvenience in the post order, it just because I didn't
switch on the mail receiving option. Now I've done it.

I was trying to adopt vv. 7.21.3 and 7.21.2, so I am basing on these
source code.

> Feel free to suggest or even provide improvements. As we already offer
> threaded resolvers using win32 or pthreads successfully it is a bit
surprising
> to me that it can't be done.

Suggestions.

1. Define 'abstract' resolving context and let the resolver to allocate
and deallocate appropriate structure for it instead of (or additionally
to) using connection.async member. The os_specific member of the
connection.async looks like appropriate for this purpose.

2. Define 'abstract' definitive calls to create and destroy resolving
context, as well as to cancel the current resolving request, like it is
already done to start (Curl_getaddrinfo) and process
(Curl_wait_for_resolv) resolving, as:

int Curl_create_resolve_context(struct connectdata *conn);

int Curl_destroy_resolve_context(struct connectdata *conn);

int Curl_cancel_resolve(struct connectdata *conn);

For example, implementation for the c-ares will look like:
int Curl_create_resolve_context(struct connectdata *conn)
{
   int status;
   ares_channel *areschannel = (ares_channel
*)Curl_malloc(sizeof(ares_channel));
   if((status = ares_init(areschannel)) != ARES_SUCCESS) {
     DEBUGF(fprintf(stderr, "Error: ares_init failed\n"));
     if(status == ARES_ENOMEM)
       return CURLE_OUT_OF_MEMORY;
     else
       return CURLE_FAILED_INIT;
   }
   conn->async.os_specific = areschannel;
   return CURLE_OK;

}

int Curl_destroy_resolve_context(struct connectdata *conn)
{
   int status;
   ares_channel *areschannel = (ares_channel*) conn->async.os_specific;
   if((status = ares_destroy(areschannel)) != ARES_SUCCESS) {
     DEBUGF(fprintf(stderr, "Error: ares_destroy failed\n"));
     return CURLE_FAILED_???;
   }
   Curl_safefree(conn->async.hostname);
   Curl_safefree(conn->async.os_specific);
   conn->async.hostname = 0;
   conn->async.os_specific = 0;
   return CURLE_OK;

}

int Curl_cancel_resolve(struct connectdata *conn)
{
   ares_channel *areschannel = (ares_channel*) conn->async.os_specific;
   if((status = ares_cancel(areschannel)) != ARES_SUCCESS) {
     DEBUGF(fprintf(stderr, "Error: ares_cancel failed\n"));
     return CURLE_FAILED_???;
   }
   return CURLE_OK;

}

These calls should be isolated to the host*.c files and requested
unconditionally from other code instead of "ifdef"-ing different
variants inside other code, f.e.:

instead of
#if defined(CURLRES_THREADED)
   Curl_destroy_thread_data(&conn->async);
#elif defined(CURLRES_ASYNCH)
   Curl_safefree(conn->async.hostname);
   Curl_safefree(conn->async.os_specific);
#endif
in the url.c (lines near to 2578)

write the following call:

Curl_destroy_resolve_context(struct connectdata *conn);

and let the resolver to make a decision, what particular structures, and
what manner, should be destroyed.

And so forth.

> if this really is a libcurl bug then you should be able to provide a
> recipe that we can use to repeat the problem in our ends. I will be
happy to
> work on hunting it down once you provide an example showing me how to
repeat
> it.

To reproduce a bug, you should:
1. Be registered as AirplaySDK developer (pay-free)
2. Have Microsoft Visual Studio installed (not obvious, but recommended)
3. Have evaluation license (pay-free 30-days) or iPhone-only license
(pay-free), or some non-free license ($99+)
4. Download and install a little airplaysdk-configure-extension
(http://code.google.com/p/airplaysdk-configure-extension/)
5. Extract archive applied here or published on AirplaySDK forum and
"start" example\example.mkb AirplaySDK project file
6. Compile and run "ARM Debug" configuration

I am especially underscoring here that I don't know, whose error really
plays a role. Moreover, I am not ever sure that the error will be
reproduced on your site as I've described, just because the error
happens irregularly. For example, I've noticed that the size of the
buffer allocated in the stack in the example to snprintf the request
result, really influences the error appearance. If i am trying to run
the example in the debug mode step-by-step - all things work fine! If I
am switching debug printing on - all things work fine! It looks very
close to memory overwriting error, and I don't know how it will break
your code. I've spent already 4 or 5 days and nights to resolve the
issue, and doesn't find anything. It's a mess.

> Also, I know lots of people already use the "stock" libcurl perfectly
fine on
> Android which indicates it isn't a generic problem on that platform.

The AirplaySDK is a multiplatform SDK (Android, iPhone, Windows Mobile
etc.) which provides some isolated OS-independent layer to the
developer. They have made different loaders for supported platforms,
which load and run the same binary code on these platforms. So it's not
an Android platform, it's AirplaySDK-On-Android platform. The same for
Windows Mobile, iPhone, Symbian etc. All things that I have in this
environment, are provided by the AirplaySDK, including POSIX-style
sockets, independently on OS. It allows to write really multiplatform
application, but with some serious restrictions. The CURL may help to
avoid some of them.

Regards,
Vsevolod Novikov

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html