[PATCH] resolv: Mirror the entire resolver configuration in struct resolv_conf

[Florian Weimer]

On 07/04/2017 01:59 PM, Andreas Schwab wrote:
> (gdb) p *resp
> $1 = {retrans = 5, retry = 2, options = 705, nscount = 1, nsaddr_list = {{
>       sin_family = 2, sin_port = 13568, sin_addr = {s_addr = 16777343}, 
>       sin_zero = "\272\272\272\272\272\272\272\272"},

Seem this is [127.0.0.1]:53.

 {sin_family = 0,
>       sin_port = 0, sin_addr = {s_addr = 0}, 
>       sin_zero = "\000\000\000\000\000\000\000"}, {sin_family = 0, 
>       sin_port = 0, sin_addr = {s_addr = 0}, 
>       sin_zero = "\000\000\000\000\000\000\000"}}, id = 0, dnsrch = {0x0, 0x0, 
>     0x0, 0x0, 0x0, 0x0, 0x0}, defdname = '\000' <repeats 255 times>, 
>   pfcode = 0, ndots = 1, nsort = 0, ipv6_unavail = 0, unused = 0, sort_list = {
>     {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {
>         s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {
>         s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {
>         s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {
>         s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}}, 
>   __glibc_unused_qhook = 0x0, __glibc_unused_rhook = 0x0, res_h_errno = 0, 
>   _vcsock = -1, _flags = 0, _u = {
>     pad = "\000\000\000\000\000\000\000\000\377\377\377\377", '\000' <repeats 39 times>, _ext = {nscount = 0, nsmap = {0, 0, 0}, nssocks = {-1, 0, 0}, 
>       nscount6 = 0, nsinit = 0, nsaddrs = {0x0, 0x0, 0x0}, 
>       __glibc_extension_index = 0}}}
> (gdb) p *conf
> $2 = {__refcount = 3, nameserver_list = 0x606f38, nameserver_list_size = 1, 
>   search_list = 0x606f40, search_list_size = 0, sort_list = 0x606f50, 
>   sort_list_size = 0, options = 705, retrans = 5, retry = 2, ndots = 1}
> (gdb) p conf.nameserver_list[0]
> $3 = (const struct sockaddr *) 0x606f40
> (gdb) p *$
> $4 = {sa_family = 2, 
>   sa_data = "\000\065\177\000\000\001\272\272\272\272\272\272\272\272"}

That looks like [127.0.0.1]:53, too.

So I don't see the mismatch.  Let's see what the additional logging will
reveal.  Sorry about this mess, but I don't see the bug so far.

Thanks,
Florian