Daniel,

Unfortunately it looks like the hostip.c patch you offered didn't help
- it crashed at the third "cycle" of using connections in my
case.. See below.

On Sun Feb 15 2004 at 18:58, Daniel Stenberg <daniel-curl_at_haxx.se> wrote:

> On Sun, 15 Feb 2004, Grigory Entin wrote:
>
> > > How many host name do you have in the cache when it crashes?
> >
> > I'm not sure exactly, as I don't know where to look for that number -
>
> It would basicly be the amount of different host names you've used.
>
> > if you give a hint I could verify it. At least I have _two_ CURL instances -
> > one is used as FTP connection to a fixed host, another as HTTP connection to
> > another host + I have HTTP proxy, and no FTP proxy - so there should be at
> > least two host names, probably more - due to redirects from HTTP replies or
> > whatever. I don't know if the cache is shared among different CURL
> > instances, sorry, that's why I give these probably irrelevant details.
>
> Each curl handle has its own cache and they are not shared unless
> specificly made so.

Yes, that is what I thought and was afraid of - it crashes for for FTP
connection, and there I guess only one hostname.

Just in case, below is what's relevant:

* Re-using existing connection! (#0)
>>
#0 0x900abfe4 in getnameinfo ()
#1 0x014fe158 in verboseconnect (conn=0x28b1c00, dns=0x16010a0) at
#url.c:1844
#2 0x014ff774 in SetupConnection (conn=0x28b1c00, hostaddr=0x0) at
#url.c:3155
#3 0x014ff7e8 in Curl_connect (data=0x4, in_connect=0xbfff6e84,
#asyncp=0xbfff6e80 "") at url.c:3194
#4 0x01506030 in Curl_perform (data=0x5038000) at transfer.c:1866
>>

If remember it correctly, it can be getnameinfo (where it crashed
right now in the above case), or (from my memory) infof call that
follows getnameinfo call, both crashes due to messed up data in the
area pointed by ai. Probably

>
> I'll try to write an internal function within a few days that'll check the
> internal state and output the cache data, so that we can make calls to that
> function at several places to help pinpoint exactly where/when this problem
> occurs.
>
> We've had others saying that removing the prune call solves this
> problem, and I guess that's the quick work-around for you as
> well. The only problem is then that by doing that, the cache will
> never be pruned...

Yes, I see. I think it's not a big problem in my case, as I'm not
switching hostnames in most cases / recreating CURLs in such cases
anyway. Anyway I'd like to help. ;)

Regards,
Grigory
Received on 2004-02-16