I've made a decision to freeze trying to plug custom async resolver into
the CURL, just because the CURL doesn't allow me to catch canceling
and/or destroying resolving contexts on the easy handle. There is a work
around to avoid using resolver inside a CURL.
Now almost stable port is made basing on CURL v.7.21.2. Using the CURL
v.7.21.3 leads to infinite connection loose after some number of
successful requests.
To: Daniel Stenberg
Really the bug, described before, (leading to segmentation fault)
happens only with custom async resolver. I've made several tests and
found, that trying to return resolving results in asynchronous manner
outside of the Curl_getaddrinfo() using Curl_addrinfo_callback() at any
point leads to stable reproducing of the bug, independently on resolving
algorithm itself. Moreover, I've found that the example using async
resolver works unstable (infinite connection loose) even when it is not
failed immediately after the start, f.e. on the Android host.
Regards,
Vsevolod Novikov
09.01.2011 02:43, Vsevolod Novikov пишет:
Hi All,
The AirplaySDK is a multiplatform SDK for mobile C/C++ applications
(for information see www.airplaysdk.com)
It contains some basic HTTP feature, but not so rich as a CURL, and
doesn't have other CURL-supported protocols, so the CURL is a good
choice to be ported under the AirplaySDK.
I've made a custom configuration for the CURL under AirplaySDK, but
met some stability problems. They look like some memory overwriting
bug, look to the www.airplaysdk.com/node/2876 page for details. The
problem is that the bug itself doesn't affect the running program
immediatelly, but probably destroys some memory structires instead, so
the result is a segmentation fault on the broken stack. I really don't
know what I can do more. Any idea?
Regards,
Vsevolod Novikov
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
