2008/10/28, Daniel Stenberg wrote:

> > Initial attempt to detect at configuration time if the getaddrinfo()
> > function returns an addrinfo with an unfreeable ai_canonname member ptr.
>
> This caught my attention. What systems have an getaddrinfo() that requires
> the separate struct fields to be free()d especially? It does seem like a
> very weird API breakage to me.

None. But keep reading :-)

System's freeaddrinfo() must be capable of free()ing whatever addrinfo
pointer has been returned by system's getaddrinfo(), and no other
method shall be used to free it.

Once that said...

I was really curious on what kind of tricks the getaddrinfo()
functions were playing on autobuild systems with the addrinfo
structure and data pointed from members of this structure. So, for one
autobuild cycle it will be attempted to find out if the ai_addr and
ai_canonname pointers can be free'd without using freeaddrinfo().
Later this check will simply be commented out.

It seems that Linux systems do a single block allocation which holds
the addrinfo struct and the data pointed by its members. And in
consequence the ai_addr and ai_canonname pointers aren't independently
freeable.

On the other hand, it seems that Windows does independant allocations
for the ai_addr and ai_canonname, and in consequence these can be
free'd.

So I wanted to know what is happening on other systems.

In any case. The above has some implications for us.

It is most probably the origin of the icc seg-fault due to at some
point directly mixing Curl_addrinfo with addrinfo structs, and later
on not being capable of knowing which Curl_freeaddrinfo or
freeaddrinfo must be used. I have not looked into this yet, so I could
be wrong about this.

If the above is somehow happening. I think that a safe approach would
be to, more or less, replace system's getaddrinfo calls in the library
with a wrapper function that calls the system getaddrinfo, allocates a
new Curl_addrinfo copying into it whatever getaddrinfo returned,
inmediately calling system's freeaddrinfo and returning the
Curl_addrinfo.

Later on there's no need to call freeaddrinfo at all. Simply use
Curl_freeadrinfo all over the place.

But I still have to look into all this later. Very soon but later.

-- 
-=[Yang]=-