On 11/3/06, Daniel Stenberg <daniel_at_haxx.se> wrote:

> > It works now with the latest curl version. There's a problem with
> > curl_easy_free() though on my system; memcmp() in /lib/tls/libc.so.6
> > segfaults. Obviously not a curl issue. I'll take it up with the Debian TLS
> > package maintainers perhaps.
>
> Well, you could still make a stack trace for us and show, and we might be able
> to spot something.

OK then. I'll get a "backtrace" from gdb next time I'm using it. I
don't know how I can do that using Microsoft's tools (testing on Linux
and Windows).

> > There is another issue. curl_easy_perform() returns an error "couldn't send
> > data to peer" even though immediately after that I get the error string and
> > the HTTP return code is 200.
>
> I don't get it. How do you get the error string and HTTP return code? What's
> the exact return code you get from curl_easy_perform() ?

I get CURLE_SEND_ERROR (I was stepping through with Visual Studio and
it was something to do with DNS). But then it works:

CURL error: failed sending data to the peer
*** RETURN SOAP ENVELOPE:

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Cache-control: private
Transfer-Encoding: chunked
Date: Fri, 03 Nov 2006 07:26:55 GMT
Server: GFE/1.3

... and so on.

> > It works, but perhaps it tries a few times, sets the error, then it works
> > and hence the bad return code but it's actually worked after a few tries?
>
> libcurl never "tries a few times" on its own.

OK. It seems like it fails sending data to do a DNS lookup, but the
actual query works fine. Sample code attached with everything ripped
out, it does a simple query to the Google SOAP Search API service. No
command line arguments necessary, just wait for the output.

-J