On Thu, 4 Sep 2003, Jurij Smakov wrote:

(Thanks for providing such excellent details on this problem, which I'm not
able to repeat since I have no access to any architecture that repeats these
sympthoms. I'm replying this to both the libcurl mailing list as well as the
debian bug tracker.)

> Here's my report on curl (version 7.10.7) on alpha. After the build, which
> seems to run pretty smoothly, it tries various tests, which fail (all of
> them). For tests it uses debian/build/src/curl, which is just a wrapper
> script around debian/build/src/.libs/lt-curl. So when I tried to run it
> directly (8999 is the port which is uses for tests, by firing up a tiny web
> server and then issuing various requests to it),

Just FYI, you can do:

 $ cd tests
 $ ./runtests.pl [num] -g

And then you'll get the particular test case run and firing up gdb for you all
ready to debug curl (with the proper command line for this particular test all
ready and setup). It then assumes that ../src/curl is a debuggable binary,
which can be accomplished by using configure --disable-shared (and
--enable-debug is also useful when debugging).

> #0 Curl_resolv (conn=0x12003dce0, hostname=0x12003dd48 "127.0.0.1",
> port=8999, entry=0x11ffff2e0) at ../../../lib/hostip.c:313
> 313 Curl_addrinfo *addr = my_getaddrinfo(conn, hostname, port,
> &wait);
>
> The backtrace from this point:
>
> #0 Curl_resolv (conn=0x12003dce0, hostname=0x12003dd48 "127.0.0.1",
> port=8999, entry=0x11ffff2e0) at ../../../lib/hostip.c:313
> #1 0x0000020000040e7c in CreateConnection (data=0x120035320,
> in_connect=0x11ffff3a8, addr=0x11ffff350, async=0x11ffff3a0 "")
> at ../../../lib/url.c:3003
> #2 0x00000200000427bc in Curl_connect (data=0x12003e620,
> in_connect=0x11ffff3a8, asyncp=0x11ffff3a0 "") at
> ../../../lib/url.c:3183
> #3 0x000002000004d8e8 in Curl_perform (data=0x120035320)
> at ../../../lib/transfer.c:1929
> #4 0x000002000004e028 in curl_easy_perform (curl=0x12003e620)
> at ../../../lib/easy.c:258
> #5 0x000000012000684c in operate (config=0x11ffff720, argc=2,
> argv=0x120035320) at ../../../src/main.c:3136
> #6 0x00000001200073fc in main (argc=2, argv=0x11ffff9b8)
> at ../../../src/main.c:3264
>
> Note, that there is no crash or something like this at this point. It is
> just that the parameters for this function call (conn, hostname, port, and
> &wait) are all correct before the call, but once you step into the
> my_getaddrinfo function, the last three of them are set to the junk
> values, which cause subsequent misbehavior.

This sounds very strange, as it makes it sounds like a stack problem or
something. I can't detect any overflows anywhere near this though...

> Attached is a gdb log, in which I try to make sure that the parameters are
> ok on assembler level, and then stepi this line until my_getaddrinfo, where
> everything goes wrong.

I'm no alpha assembler guru, but I think it looks like it reads the variables
into the a0-a3 registers from the stack, and when those are passed into the
function it jumps to, they are very wrong. It does indicate that something in
the CreateConnection() function has destroyed the data before this.

If you single-step again, and display the values for these variables earlier
on in the CreateConnection() function, can you see when they change to bad
values?

Thanks a lot for your help!

(BTW, I am the upstream main author of curl and libcurl).

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf