Daniel,

On Mon Feb 16 2004 at 13:03, Daniel Stenberg <daniel-curl_at_haxx.se> wrote:

> On Mon, 16 Feb 2004, Grigory Entin wrote:
>
> > * 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
>
> Eeek. This is badness. What I don't understand in this sequence is
> that 'hostaddr' comes in to SetupConnection() as a NULL, but is
> later passed on to verboseconnect() as a pointer... Can you figure
> out why this happens? AFAICS, it should be passed on untouch as a
> NULL.

I checked that in gdb, it looks like a side-effect of optimization, I
can confirm that I see how hostaddr passed as NULL, and initially bt
reports that fact inside verboseconnect, but soon after two
"unexpected jumps" in the source, it's reported as not-NULL.

> > 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.
>
> I believe this verboseconnect() function is a bit stupid in the
> ipv6-part when we reuse connections (and the pointer is NULL as
> above). Can you see if the attached patch makes life happier for
> your test-case? Thinking about it, it will only do so if
> verboseconnect() get that NULL pointer passed in, not otherwise.

Ok, it looks like it helped. Thanks! The only question - should I
apply _both_ hostip.c patch and verboseconnectipv6 (I applied both)
or only the last one?

Regards,
Grigory
Received on 2004-02-16