Re: getaddrinfo(3) / AI_ADDRCONFIG

[Rich Felker <dalias@libc.org>]

On Tue, Jul 10, 2018 at 08:05:50AM -0400, Christopher Friedt wrote:
> On Mon, Jul 9, 2018, 9:00 PM Rich Felker, <dalias@libc.org> wrote:
> 
> > Can you provide a minimized test case (short single C source file) to
> > reproduce this, or an strace log of the test that fails? The latter is
> > probably actually be better if the behavior is dependent on the Docker
> > network configuration. Assuming the test is attempting to lookup and
> > bind on "localhost" by name, which is what it appears to be doing
> > here:
> >
> >
> > https://github.com/apache/thrift/blob/82ae9575cdc112088771fc7b876f75e1e4d85ebb/lib/cpp/test/TServerSocketTest.cpp
> >
> > the behavior you're experiencing is not what I expect from musl;
> > rather my expectation is that you would get 127.0.0.1 as the first
> > result and ::1 as the second, and this is exactly what I see if I do:
> >
> > ip addr del ::1 dev lo
> >
> > on my laptop running Alpine, then call getaddrinfo for localhost with
> > a small test program.
> >
> > The logic to sort results does gratuitously depend on v4mapped
> > addresses working to do the IPv4 routability probing; if something
> > about the configuration suppresses their ability to work, it will
> > break. This is a known open issue I want to go back and fix. Seeing
> > the strace would show me right away if it's the source of your
> > problem, and even if not chances are very good that it would point out
> > whatever the cause is.
> >
> 
> Strange - yeah, I'll write up a small program in C to demonstrate.

OK. Can you also post the results of:

	strace -o logfile your_test_prog

This avoids the need for me or someone else to reproduce the full
configuration to see what's going on. strace output is almost
certainly the fastest path to a solution.

Rich